[Gllug] Mercurial or Subversion for single user?

[Nix]

On 24 Mar 2010, Richard Jones uttered the following:

> On Wed, Mar 24, 2010 at 12:44:08AM +0000, Nix wrote:
>> It adds *the actual file*, i.e. the *actual content* to the 'index'
>> (also known as the 'cache' or 'staging area', which is a sort of limbo
>> files go into before commit. Change the file after 'git add' then do a
>> 'git commit', and the thing you added, *without that change*, is what
>> gets committed, because what gets added is what's in the index, and the
>> index hasn't changed since you did a 'git add'.
>
> Yup, the index is an odd and oddly great concept.  It does take a bit
> of getting used to, and is quite unlike any other VCS (AFAIK?)

I just wish the naming wasn't so damn inconsistent. Some commands have
an --index option, some have --staging, some have --cache, and not
only do some of these options do the same, in other commands identically-
named options do different things.

It's a bloody mess, and I'm half-inclined to commit a local patch
cleaning it up (though Junio has already rejected the idea of fixing it
upstream, gah).

Equally, the opposite of 'git add' *should* obviously be named something
like 'git remove', but isn't. This at least is easy to fix with two lines
in .gitconfig:

[alias]
        remove = reset --

>> (If the changes touch some of the same files, this won't work quite so
>> easily, but 'git add -p' lets you add only *chunks* of changed files,
>> similar to darcs.)
>
> Don't forget the awesome power of the 's' key (in git add -p mode),
> which splits up the hunks to be smaller and smaller.  This means you
> can split up even closely related changes.  And (I discovered the
> other day) you can even edit the hunks manually before they get added.

Ooo. I never noticed that feature, somehow, even though it's documented.
That makes it even more useful :)

> What I actually do if I'm randomly hacking on different features, is
> to commit it all and frequently (using --amend), then:
>
>   git reset --mixed HEAD^
>
> to completely undo the whole commit, and add/commit it in logical
> chunks.

I tend to do a bunch of commits, then redo it in a sane fashion on
another branch. I suspect your approach is easier, and will adopt it
from now on, now that I know about the s key :)

> Rebasing / rewriting history has completely changed how I think and
> present patches.

Quite so. No longer is 'commit' a heavyweight 'be terrified' option;
it's something you do because you want to try something else, or
because you're getting a coffee, or for any other reason that grabs
your whim. It's pushing that you should now be terrified of :)

> Then there's 'git reflog', which means as long as you committed the
> change at some point, you're never going to lose it, short of a hard
> disk failure.

Well, if you revert something and then need it many weeks later, the
reflog might have expired: but if you catch yourself doing that a
lot you can turn off reflog expiry at the cost of some disk space
(OK, if you do a lot of big rebases, quite a lot of disk space).
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug