6 ms·

Gitless: an experimental version control system built on top of Git

67 points by rrrrtttt 13y ago

dominotw 13y ago
I don't understand what it is supposed to do. > Check out the documentation section to get started. > Documentation: TODO.
- deleted 13y ago
  [deleted]
- skrebbel 13y ago
  There must be a dead link somewhere. If I follow the documentation link in the top menu, I get to docs.
- odonnellryan 13y ago
  I see the documentation. Seems to be Git without Commits - kind of. It seems to be better described here: > Unlike traditional version control systems (such as CVS and Subversion), Gitless is distributed. Rather than having a single, centralized repository, each user has her own repository that is synchronized with other repositories.
  - quarterto 13y ago
    That quote can be applied verbatim (but for s/Gitless/Git) to Git itself.
    - odonnellryan 13y ago
      That's true.
  - orclev 13y ago
    Near as I can tell, the only difference is that they added this concept of tracked vs. untracked files. When you do a commit, everything that's currently tracked gets included in the commit unless you specifically list a set of files to include or ignore when you make the commit. As a side effect they seem to have removed the concept of a staging area. Functionally it's a lot like every commit has the -a flag set and anything that's "untracked" is in your .gitignore file. I've not seen any other differences, although some other comments have mentioned some difference with regards to the way branches are handled.
quarterto 13y ago
So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.
- skrebbel 13y ago
  From what I can see: easier control over tracked/untracked status of files; no stage (might be considered a disadvantage, though I'll wager a good interactive commit feature would render a stage unnecessary), automatically commit everything by default, much simpler concept of what a branch is and isn't; no fetch at all, just merge. I like this experiment quite a lot. It's clearly very incomplete and lacking of features, but I feel that it gets the basic concepts more right than Git does. For example, the idea that merging from a local branch or merging from a remote branch is the same, is very nice and simple. Sure, it's not like 'git pull' vs 'git merge' is a lot more work, but still, I'd like to not be bothered by the difference. There's a whole bunch of edge cases still missing here, I fear, but I really like where this is heading. Would use.
  - hosh 13y ago
    I see, so they are experimenting with the user experience, probably by examining assumptions and see how much can be cut away and still be functional.
  - Peaker 13y ago
    The staging area is sort of a UI for "interactive" commit. But one that can persist the partial commit state across multiple commands, or until you can finish the work tomorrow. An interactive commit interface which loses the accepted/rejected changes if you have to close it for one reason or another is going to be worse than the git UI for interactive commits.
- Alphasite_ 13y ago
  Wasn't Git conceived as an api instead of a straight up all-in-one VCS?
  - 13y ago
couchand 13y ago
It looks like there's no concept of a stage, which would imply that commits can only be made at a file level. This nerfs the single greatest feature of git: git add -p
- michaelmior 13y ago
  git add -p could just be replaced with git commit -p without adding a stage. Although it doesn't seem like this is what Gitless does at the moment.
  - StavrosK 13y ago
    I would think that this is exactly what's expected in an experiment like this.
justinsb 13y ago
A nice project: Git is a wonderful version control system, but the git cli (the porcelain) definitely has some annoyances. I think submodules, for example, are completely broken at the CLI level. I don't think this project necessarily goes far enough though; the biggest change I saw was getting rid of the staging area. Whether or not that's a good idea, I was hoping for crazier ideas! For example, how about something that is more aware of github, where my github branches auto-update, and works nicely with forks, pull-requests and issues. The git-review integration for gerrit is interesting along those lines: https://pypi.python.org/pypi/git-review https://pypi.python.org/pypi/git-review
- ash 13y ago
  I think git-subtree is a better approach than what submodules are doing. Adding a submodule breaks things. E.g. `git clone` stops working as it should. In contrast, git-subtree doesn't break anything, because it just merges another repo history into the main repo: https://github.com/apenwarr/git-subtree https://github.com/apenwarr/git-subtree (also in git contrib/)
- graywh 13y ago
  Github released a tool called "hub" that you might be interested in. https://github.com/github/hub https://github.com/github/hub
girvo 13y ago
Hah. This makes me think of a quote I remember: Git is an excellent library for building a DVCS. ;)
michaelmcmillan 13y ago
If Linus gets a hold of any of you guys, for just a second..
- alerkay 13y ago
  I thought Linus had mostly worked on the inner workings of Git (the "plumbing"). These are awesome. But the CLI part is not straightforward at all. I keep seeing people new to Git having great pain to use it. So, if some new folks come up and expose clearer CLI concepts than Git does, then I completely agree with their initiative. On top of that, if it remains compatible with existing Git repositories, then I will surely give it a try and maybe use it regularly.
farginay 13y ago
I wish the page described what the goal actually is - and what gitless is. This is very hard to parse: "We are exploring what conceptual integrity means with the goal of building a rigorous foundation for concept design." Huh?
Fomite 13y ago
Looks interesting, but front page doesn't do a great idea with selling me on why I should spend a couple hours of my day experimenting. What will this do for me?
js2 13y ago
See also EasyGit - https://people.gnome.org/~newren/eg/ https://people.gnome.org/~newren/eg/
ealdent 13y ago
Should be renamed Pointless. We challenge all the basic assumptions of VCS and conclude ... git was right all along it just needs some syntactic sugar.
dack 13y ago
I'm all for reimagining the concepts that go into version control, standing on Git's shoulders. However, I think this is way too close to normal git for me to think it's useful. It might be simpler in ways, but it feels more complicated in others. For example, branches are pretty much the simplest concept you can think of in Git currently - just pointers to commits (referenced by name). Trying to think of them as separate lines of development actually makes me a little nervous that I would clobber some history somehow. Anyway, that's not to discourage the effort - this is how we move development forward.
4ad 13y ago
I wish people compared new DVCS with git and mercurial, not with svn and cvs. That's incredibly unhelpful now that everyone is familiar with DVCS.
CodeMage 13y ago
"if we were to challenge the very core concepts in version control systems, what would version control look like?" I looked at the documentation and I see nothing that challenges the very core concepts in version control systems. Did I miss something?

67 points by rrrrtttt 13y ago

I don't understand what it is supposed to do. > Check out the documentation section to get started. > Documentation: TODO.

deleted 13y ago
[deleted]
skrebbel 13y ago
There must be a dead link somewhere. If I follow the documentation link in the top menu, I get to docs.
odonnellryan 13y ago
I see the documentation. Seems to be Git without Commits - kind of. It seems to be better described here: > Unlike traditional version control systems (such as CVS and Subversion), Gitless is distributed. Rather than having a single, centralized repository, each user has her own repository that is synchronized with other repositories.
- quarterto 13y ago
  That quote can be applied verbatim (but for s/Gitless/Git) to Git itself.
  - odonnellryan 13y ago
    That's true.
- orclev 13y ago
  Near as I can tell, the only difference is that they added this concept of tracked vs. untracked files. When you do a commit, everything that's currently tracked gets included in the commit unless you specifically list a set of files to include or ignore when you make the commit. As a side effect they seem to have removed the concept of a staging area. Functionally it's a lot like every commit has the -a flag set and anything that's "untracked" is in your .gitignore file. I've not seen any other differences, although some other comments have mentioned some difference with regards to the way branches are handled.

quarterto 13y ago

So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.

skrebbel 13y ago
From what I can see: easier control over tracked/untracked status of files; no stage (might be considered a disadvantage, though I'll wager a good interactive commit feature would render a stage unnecessary), automatically commit everything by default, much simpler concept of what a branch is and isn't; no fetch at all, just merge. I like this experiment quite a lot. It's clearly very incomplete and lacking of features, but I feel that it gets the basic concepts more right than Git does. For example, the idea that merging from a local branch or merging from a remote branch is the same, is very nice and simple. Sure, it's not like 'git pull' vs 'git merge' is a lot more work, but still, I'd like to not be bothered by the difference. There's a whole bunch of edge cases still missing here, I fear, but I really like where this is heading. Would use.
- hosh 13y ago
  I see, so they are experimenting with the user experience, probably by examining assumptions and see how much can be cut away and still be functional.
- Peaker 13y ago
  The staging area is sort of a UI for "interactive" commit. But one that can persist the partial commit state across multiple commands, or until you can finish the work tomorrow. An interactive commit interface which loses the accepted/rejected changes if you have to close it for one reason or another is going to be worse than the git UI for interactive commits.
Alphasite_ 13y ago
Wasn't Git conceived as an api instead of a straight up all-in-one VCS?
- 13y ago

couchand 13y ago

It looks like there's no concept of a stage, which would imply that commits can only be made at a file level. This nerfs the single greatest feature of git: git add -p

michaelmior 13y ago
git add -p could just be replaced with git commit -p without adding a stage. Although it doesn't seem like this is what Gitless does at the moment.
- StavrosK 13y ago
  I would think that this is exactly what's expected in an experiment like this.

justinsb 13y ago

A nice project: Git is a wonderful version control system, but the git cli (the porcelain) definitely has some annoyances. I think submodules, for example, are completely broken at the CLI level. I don't think this project necessarily goes far enough though; the biggest change I saw was getting rid of the staging area. Whether or not that's a good idea, I was hoping for crazier ideas! For example, how about something that is more aware of github, where my github branches auto-update, and works nicely with forks, pull-requests and issues. The git-review integration for gerrit is interesting along those lines: https://pypi.python.org/pypi/git-review https://pypi.python.org/pypi/git-review

ash 13y ago
I think git-subtree is a better approach than what submodules are doing. Adding a submodule breaks things. E.g. `git clone` stops working as it should. In contrast, git-subtree doesn't break anything, because it just merges another repo history into the main repo: https://github.com/apenwarr/git-subtree https://github.com/apenwarr/git-subtree (also in git contrib/)
graywh 13y ago
Github released a tool called "hub" that you might be interested in. https://github.com/github/hub https://github.com/github/hub

girvo 13y ago

Hah. This makes me think of a quote I remember: Git is an excellent library for building a DVCS. ;)

michaelmcmillan 13y ago

If Linus gets a hold of any of you guys, for just a second..

alerkay 13y ago
I thought Linus had mostly worked on the inner workings of Git (the "plumbing"). These are awesome. But the CLI part is not straightforward at all. I keep seeing people new to Git having great pain to use it. So, if some new folks come up and expose clearer CLI concepts than Git does, then I completely agree with their initiative. On top of that, if it remains compatible with existing Git repositories, then I will surely give it a try and maybe use it regularly.

farginay 13y ago

I wish the page described what the goal actually is - and what gitless is. This is very hard to parse: "We are exploring what conceptual integrity means with the goal of building a rigorous foundation for concept design." Huh?

Fomite 13y ago

Looks interesting, but front page doesn't do a great idea with selling me on why I should spend a couple hours of my day experimenting. What will this do for me?

js2 13y ago

See also EasyGit - https://people.gnome.org/~newren/eg/ https://people.gnome.org/~newren/eg/

ealdent 13y ago

Should be renamed Pointless. We challenge all the basic assumptions of VCS and conclude ... git was right all along it just needs some syntactic sugar.

dack 13y ago

I'm all for reimagining the concepts that go into version control, standing on Git's shoulders. However, I think this is way too close to normal git for me to think it's useful. It might be simpler in ways, but it feels more complicated in others. For example, branches are pretty much the simplest concept you can think of in Git currently - just pointers to commits (referenced by name). Trying to think of them as separate lines of development actually makes me a little nervous that I would clobber some history somehow. Anyway, that's not to discourage the effort - this is how we move development forward.

4ad 13y ago

I wish people compared new DVCS with git and mercurial, not with svn and cvs. That's incredibly unhelpful now that everyone is familiar with DVCS.

CodeMage 13y ago

"if we were to challenge the very core concepts in version control systems, what would version control look like?" I looked at the documentation and I see nothing that challenges the very core concepts in version control systems. Did I miss something?