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/
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.
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.
At least from my small sample size of people, that is true.
Also git-gui can stage individual lines.
Even though he had never checked in code it was still saved into the VCS. That is pretty powerful.
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.
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.
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.
There then were a couple different porcelains written and discarded in favor of what we have now.
> Check out the documentation section to get started.
> Documentation: TODO.
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.
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.
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://github.com/apenwarr/git-subtree
(also in git contrib/)
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?
Anyway, that's not to discourage the effort - this is how we move development forward.
We challenge all the basic assumptions of VCS and conclude ... git was right all along it just needs some syntactic sugar.
I looked at the documentation and I see nothing that challenges the very core concepts in version control systems. Did I miss something?