I appreciate mercurial existing and I think there are lots of good ideas, but I _really really really really_ like the working tree/staging area/index model of git. It works so well for allowing commits to be done cleanly, even when the initial work is likely not done that cleanly.
I don't fully believe this, but I kind of believe that having the staging model is what allows git to be very good at modelling almost anything nicely. New workflows can be easily rolled out because we have this phase separation between committing and simply staging.
And just as a general thing, `git add -p` totally made me a better developer overnight, at least in terms of actually rereading my changes seriously (and fixing them up etc). The model isn't necessary to this kind of workflow but it helps!
> I appreciate mercurial existing and I think there are lots of good ideas, but I _really really really really_ like the working tree/staging area/index model of git.
> Git is the only DistributedSCM that exposes the concept of index or staging area. The others may implement and hide it, but in no other case is the user aware or has to deal with it.
> Mercurial's rough equivalent is the DirState, which controls working copy status information to determine the files to be included in the next commit. But in any case, this file is handled automatically. Additionally, it is possible to be more selective at commit time either by specifying the files you want to commit on the command line or by using hg commit --interactive.
[…]
> If you need the index, you can gain its behavior (with many additional options) with mercurial queues (MQ). Simple addition of changes to the index can be imitated by just building up a commit with hg commit --amend (optionally with --secret, see phases).
Oh, to be clear, I’m a huge fan of git add -p. I also use TortoiseHG’s equivalent feature.
What I don’t like is that git’s index is called an index (what does “index” have to do with its usecases?) and that the index is live even when you don’t want it. It should be opt-in, not opt-out.
> I would very much like hg to have an equivalent of `git commit -p` and `git commit -v`, agreed.
See perhaps:
> ! This extensions is deprecated, the feature is now part of Mercurial core as hg commit --interactive.
> The record extension provides the record command, which may be used in lieu of commit. This command lets you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks. It is similar in spirit to the darcs record command.
TortoiseHG can do this, more or less. I find that I sometimes need to click a couple times on the revision list to change the state and change it back to get the correct commit view to show up, but it usually cooperates.
I don't fully believe this, but I kind of believe that having the staging model is what allows git to be very good at modelling almost anything nicely. New workflows can be easily rolled out because we have this phase separation between committing and simply staging.
And just as a general thing, `git add -p` totally made me a better developer overnight, at least in terms of actually rereading my changes seriously (and fixing them up etc). The model isn't necessary to this kind of workflow but it helps!