On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> [ about micro commits ]
>> (As a side benefit, if one of my little micro-commits turns out to
>> have a bug, you can easily revert *just that commit*, without having
>> to manually sort out exactly which pieces related to that change.)
>
> I don't actually have a lot of faith in such an approach. My experience
> is that bugs arise from unforeseen interactions of changes, and that
> "backing out just one" isn't a useful thing to do, even if none of the
> later parts of the patch directly depend on it.
>
> So, yeah, presenting a patch as a series of edits can be useful for
> review purposes, but I'm not at all excited about cluttering the
> long-term project history with a zillion micro-commits. One of the
> things I find most annoying about reviewing the current commit history
> is that Bruce has taken a micro-commit approach to managing the TODO
> list --- I was seldom so happy as the day that disappeared from CVS,
> because of the ensuing reduction in noise level.
I've never even noticed that noise, even when reviewing older history.The power of "git log" to get you exactly the
commitsyou care about
is not to be underestimated.
With regard to micro-commits, I don't have hugely strong feelings on
the issue. I like them in certain situations, and I think that git
makes it feasible to use them that way if you want to; but if you
don't want to, I don't think that's a disaster either.
...Robert
