Re: question concerning branches

Avery Pennarun [off-list ref] writes:

This is a big difference from how centralized VCSs work: there, a
commit is a major operation that you're afraid to do in case you make
someone else mad.  In git, commits are cheap, you just need to be
careful about pushing.

I second this. "commit" is indeed a bad name in decentralized VCSs.
There's no commitment from the developer, you don't commit to swear
the code is good, but you commit just to record a set of changes, and
attach a descriptive message to it.

In Git, a commit takes usually a fraction of a second, and can be
modified later easily until it's pushed.

'git commit --amend' will allow you to change either the changes or
the message associated to a commit.

'git reset HEAD^' will just undo the commit, turning your commited
changes into uncommited ones.

'git rebase --interactive' will allow you another bunch of cool
things.

So, keeping your changes uncommited has very few advantage, and indeed
has one big drawback: uncommited changes have no descriptive message
associated, so if you leave a branch for some time, it makes it more
difficult for you to remember what you were doing on it when you
switch back to it:

git checkout -b topic-branch
# edit foo.bar
git checkout master
# hack
git commit
# go on holiday
# come back
git checkout topic-branch
git status
# err, what is this all about?

OTOH:

git checkout -b topic-branch
# edit foo.bar
git commit -m "started feature foo, but bar is still to be done"
git checkout master
# hack
git commit
# go on holiday
# come back
git checkout topic-branch
git show
# Ah, I remember!

Actually, all the VCSs I know about (Mercurial, Bazaar, Subversion,
and IIRC GNU Arch) deal with this the way Git does. Hey! there must be
a reason ;-).

-- 
Matthieu