Re: question concerning branches

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Aug 20, 2009, 07:57 UTC
Message-ID: <vpqzl9urk6y.fsf@bauges.imag.fr>
In-Reply-To: <32541b130908191250w79461592vf1bed7874aa4138b@mail.gmail.com>

Avery Pennarun <apenwarr@gmail.com> 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