Re: Volume of commits

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 12, 2007, 13:59 UTC
Message-ID: <Pine.LNX.4.64.0707121451290.4516@racer.site>
In-Reply-To: <20070712132937.GQ19386@genesis.frugalware.org>

Hi,

On Thu, 12 Jul 2007, VMiklos wrote:

Show 10 quoted lines

> Na Thu, Jul 12, 2007 at 03:16:47PM +0200, Fredrik Tolf <fredrik@dolda2000.com> pisal(a):
> > So what I'm wondering is how you people manage to do this? Do you 
> > actually always commit changes this way (and, in that case, how do you 
> > switch between branches)? Or do you somehow aggregate the smaller 
> > commits into larger patches and recommit them? Or is there some third 
> > possibility that I'm missing?
> 
> you can cherry-pick the relevan patches to a separate branch and commit 
> then at once (cherry-pick -n), or can merge --squash to archive 
> something similar

What I do these days is committing early, and often, and then rearrange with "git rebase -i". Beware: this is a 1.5.3 feature! But IMHO it is really something you can look forward to.

A little diagram hopefully explains what you can do with it:

- upstream
 \
   A - B - C - D - E - F - G - HEAD with a messy history

In this case, "messy history" means that there are tiny patches which are often in the wrong order, or should be squashed into one commit. "git rebase -i upstream" presents you with the list of A - HEAD, and you can reorder the patches. If you want to, you can combine ("squash") some into one commit, or you can skip it, by removing the corresponding line.

The result can look like this:

- upstream
 \
   B+C+F - A - G+E

Note that D is missing, which can be desirable, for example when you made a commit only introducing lots and lots of debug output. See, nobody has to know what you did. The end result will look elegant.

This demonstration of why distributed SCM is good ("it lowers the 
embarrasment factor") was brought to you by Git.
 
Ciao,
Dscho