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.
> 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
