Re: Volume of commits

From: Karl Hasselström <kha@treskal.com>
Date: Jul 12, 2007, 13:49 UTC
Message-ID: <20070712134958.GA28310@diana.vm.bytemark.co.uk>
In-Reply-To: <m3ps2xu5hc.fsf@pc7.dolda2000.com>

On 2007-07-12 15:16:47 +0200, Fredrik Tolf wrote:

> When I develop for myself, I usually commit incrementally quite a
> bit, if for no other reason because Git won't let me switch between
> branches if I don't commit first.

You can switch branches even if you have local modifications if you use the -m flag to git-checkout.

Show 9 quoted lines

> I usually try to keep my commits well-defined, but I don't manage to
> get anywhere close to what I see when I look at the history of Linux
> or Git.
>
> 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?

When it's time to post patches for review on the mailing list, people clean up the history so that it'll be easier for the reviewers to read (and to make the permanent history easier to read in case the patches are accepted). Of course, with practice one can write clean patches to begin with, at least for simpler changes, but the conceptual workflow is along the lines of:

  1. Do the changes, and make sure everything works.

  2. Rewrite your changes as a series of easy-to-read and mostly
     independent patches, and make sure that everything compiles and
     just generally makes sense at all intermediate steps. The
     maintainer might very well accept some of your patches but not
     all!

  3. Repeat until you're satisfied with the result.

The rationale for spending time making history legible is the same as for making the end result code legible: stuff is written once by one person, and read many times by many people.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle