Gitless: an experimental version control system built on top of Git(people.csail.mit.edu)
people.csail.mit.edu
Gitless: an experimental version control system built on top of Git
http://people.csail.mit.edu/sperezde/gitless/
13 comments
So... what advantages does this provide over straight Git? Reading the docs, it doesn't appear to abstract over Git at all.
It removes the staging area, which also removes one of the more powerful tools in git for teasing apart work into distinct ideas, whether for creating a sensible commit history, or to separate "tangled" work into different branches. For example:
[1] Cf. Steve Losh's infamous "Git Koans": http://stevelosh.com/blog/2013/04/git-koans/
1. Write code
2. Realize it's more than you want to commit at a go
3. Stage just the files (or hunks, using `git add -i`) you want
4. git stash
5. confirm tests still work
6. git commit
7. git stash pop
8. continue working, committing, etc.
[1] Cf. Steve Losh's infamous "Git Koans": http://stevelosh.com/blog/2013/04/git-koans/
The staging area is only a powerful and necessary tool if you believe in the Commits Are Immutable rule (i.e. "don't rewrite history"). If you believe in that rule then you have to have a special mutable commit called the staging area, for when you're halfway through creating a commit.
But if you believe in rewriting history, then you can just use the tip of the working branch as a staging area. This would eliminate a whole slew of nonorthogonal git commands.
Personally I believe that branches should be explicitly designated as mutable (private "work" branches) or immutable (published branches): this gets you the best of both worlds. It's a shame Git doesn't have any tools to enforce that distinction.
But if you believe in rewriting history, then you can just use the tip of the working branch as a staging area. This would eliminate a whole slew of nonorthogonal git commands.
Personally I believe that branches should be explicitly designated as mutable (private "work" branches) or immutable (published branches): this gets you the best of both worlds. It's a shame Git doesn't have any tools to enforce that distinction.
> It's a shame Git doesn't have any tools to enforce that distinction.
Because, by design, Git can't ever know. Example one: a read-only repo can be fully cloned, meaning that all the branches therein should technically be "public". But the cloned repo is read-only so there's no way to add metadata to its branches. Example two: a developer "publishes" her entire repo to a wholly private offsite remote at the end of each day as a backup mechanism. All branches should be marked "public", but that would be wrong since they weren't exposed to any other person. I've recently worked in a shop where all <name>/<topic> branches in the main repo were considered logically private unless by prior agreement. Publishing was defined as merging to master; rebasing a logically private branch was perfectly OK (and frequently mandatory).
More to the point: it's not git's job to be overly "smart", especially in ways that require mind-reading. git provides a powerful "algebra of version control", where at some point even the "porcelain" commands can really be seen as "plumbing". In this light, I'm all in favor of higher levels of workflow porcelain. In fact, many larger teams I've worked with accrete such a layer out of necessity. Communicating and performing policy as folk knowledge eventually fails to scale, and tools pick up the slack. So the workflow you describe could be encoded as the Opinionated Policy of a tool on top of git which fills in the missing info in the scenarios above.
This reveals something I find disappointing about TFA: the lack of design exposition about its approach. Also, it appears to be trying to address VCS design without actually talking at all about what's known about the problem space to date. IMO this stands in stark contrast to the current generation of DVCS tools where the players (git, hg, bzr, darcs, etc.) each communicated around a set of concrete lessons learned from prior VCS systems.
Because, by design, Git can't ever know. Example one: a read-only repo can be fully cloned, meaning that all the branches therein should technically be "public". But the cloned repo is read-only so there's no way to add metadata to its branches. Example two: a developer "publishes" her entire repo to a wholly private offsite remote at the end of each day as a backup mechanism. All branches should be marked "public", but that would be wrong since they weren't exposed to any other person. I've recently worked in a shop where all <name>/<topic> branches in the main repo were considered logically private unless by prior agreement. Publishing was defined as merging to master; rebasing a logically private branch was perfectly OK (and frequently mandatory).
More to the point: it's not git's job to be overly "smart", especially in ways that require mind-reading. git provides a powerful "algebra of version control", where at some point even the "porcelain" commands can really be seen as "plumbing". In this light, I'm all in favor of higher levels of workflow porcelain. In fact, many larger teams I've worked with accrete such a layer out of necessity. Communicating and performing policy as folk knowledge eventually fails to scale, and tools pick up the slack. So the workflow you describe could be encoded as the Opinionated Policy of a tool on top of git which fills in the missing info in the scenarios above.
This reveals something I find disappointing about TFA: the lack of design exposition about its approach. Also, it appears to be trying to address VCS design without actually talking at all about what's known about the problem space to date. IMO this stands in stark contrast to the current generation of DVCS tools where the players (git, hg, bzr, darcs, etc.) each communicated around a set of concrete lessons learned from prior VCS systems.
Except that in practice people tend not to perform steps 4, 5 and 7. They then commit non-working code and honestly believe that their commit is OK, because they saw all tests pass.
So, what, if people aren't using the full power of Git, the response is to remove that power? That seems completely backwards. The response should be to educate people on proper development practices.
I think the people well-versed enough in git to use "git add -p" to review their own changes, and commit them separately, are the same people that would correctly test their commits.
At least from my small sample size of people, that is true.
At least from my small sample size of people, that is true.
This is definitely not true for the outsource companies here in the 3rd world.
It gets even worse when you face people who have used SVN for years. Once they realize that they can commit non-working code on their feature branch as long as the result of the final merge into master is OK, they start to dump random work-in-progress stuff into git repo. As the result, blame and bisect are completely broken, but who cares, that's another developer who would feel the pain trying to make sense from the changeset history two years from now, not you.
It gets even worse when you face people who have used SVN for years. Once they realize that they can commit non-working code on their feature branch as long as the result of the final merge into master is OK, they start to dump random work-in-progress stuff into git repo. As the result, blame and bisect are completely broken, but who cares, that's another developer who would feel the pain trying to make sense from the changeset history two years from now, not you.
One way to mitigate that is to always squash-merge the suspect work. In some orgs, it's really hard to establish a culture of good "git hygiene". Typically CI is already branch-focused, and the merging process after CI/review/etc. is tailored to just throw out the "noise" from the incoming branches.
This also handles issues such as staff who just don't get that long-lived, continually remerged (from master) branches are evil when viewing history using `git log --graph` or similar GUI views.
This also handles issues such as staff who just don't get that long-lived, continually remerged (from master) branches are evil when viewing history using `git log --graph` or similar GUI views.
Nifty trick: use `git stash --keep-index save` to leave the staged changes around while stashing the unstaged ones. Then run your tests, muddle around and fix things as necessary, and commit. Then `git stash pop` and you have all your changes back. It seems obvious to me that this behavior should be the default for `git stash` but it isn't. Thank goodness for aliases.
Having untangled ideas using hunks, when diff doesn't choose the desired boundaries I'm not quite sure it's worth it. Certainly an engaging exercise.
Agreed, I don't tend to use `git add -i` much directly either. I use editor integrations and/or a GUI tool that allows line-by-line staging. I rather like Git Tower's[1] approach: it's easy to stage directly in the diff view either by hunk or by selected lines. This works nicely because most of the time the diff hunk(s) are OK, and I only need to mess with a selection in the less common cases.
[1] http://www.git-tower.com/
[1] http://www.git-tower.com/
You can split hunks down to individual lines.
Also git-gui can stage individual lines.
Also git-gui can stage individual lines.
You can, but last time I tried it was only via editing the diffs ('e' command in `git add -p`), which is unpleasant and sometimes pretty annoying (ah, how many times I missed the leading space on context line to have it shout at me with incomprehensible errors). (And yeah, I'm just using `git gui` for this now.)
I once recovered a commit that someone had staged and reverted.
Even though he had never checked in code it was still saved into the VCS. That is pretty powerful.
Even though he had never checked in code it was still saved into the VCS. That is pretty powerful.
You mean git stash --keep-index in 4) right?
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.
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.
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.
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.
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.
Wasn't Git conceived as an api instead of a straight up all-in-one VCS?
There is a one-off line from Linus in the early days, and some interpretable evidence in its design, that suggests this is true.
It's not what I would call strong evidence, but then again: if you're building an API without a clear consumer, it'd be worthwhile to build your own consumer too. Especially if you're your own market.
It's not what I would call strong evidence, but then again: if you're building an API without a clear consumer, it'd be worthwhile to build your own consumer too. Especially if you're your own market.
My understanding from reviewing the history is more that Linus wrote enough of git for him to be able to use it himself and then said "If other people want to use this, they may need to add some porcelain on top of it"
There then were a couple different porcelains written and discarded in favor of what we have now.
There then were a couple different porcelains written and discarded in favor of what we have now.
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
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
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
(also in git contrib/)
https://github.com/apenwarr/git-subtree
(also in git contrib/)
Github released a tool called "hub" that you might be interested in.
https://github.com/github/hub
https://github.com/github/hub
Hah. This makes me think of a quote I remember: Git is an excellent library for building a DVCS. ;)
I don't understand what it is supposed to do.
> Check out the documentation section to get started.
> Documentation: TODO.
> Check out the documentation section to get started.
> Documentation: TODO.
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.
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.
That quote can be applied verbatim (but for s/Gitless/Git) to Git itself.
That's true.
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.
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.
[deleted]
There must be a dead link somewhere. If I follow the documentation link in the top menu, I get to docs.
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.
Anyway, that's not to discourage the effort - this is how we move development forward.
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
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.
I would think that this is exactly what's expected in an experiment like this.
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.
We challenge all the basic assumptions of VCS and conclude ... git was right all along it just needs some syntactic sugar.
"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?
I looked at the documentation and I see nothing that challenges the very core concepts in version control systems. Did I miss something?
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?
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.
See also EasyGit - https://people.gnome.org/~newren/eg/
If Linus gets a hold of any of you guys, for just a second..
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.
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.
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?