On Fri, Jun 5, 2009 at 11:37 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> However, given that we don't do any real development on the back
> branches, it might be that trying to be smart about this is a waste of
> time anyway. Surely only the HEAD version of the patch is going to be
> something that other developers care about merging with.
I think that's about right. I think there would be some benefit in
developning better tools - release notes seem to be the main issue -
so that, for example, if I develop a complex feature and you think my
code is great (ok, now I'm dreaming), you could actually merge my
commits rather than flattening them. The EXPLAIN stuff I'm working on
right now is a good example where it's a lot easier to review the
changes piece by piece rather than as a big unit, but I know you won't
want to commit it that way because (1) with CVS, it would be a lot
more work to do that, and (2) it would suck a lot of extra commits
into the data you use to generate release notes, thereby making that
process more complex.
I'm actually going to the trouble of trying to make sure that each of
my commits does one and only one thing that can be separately checked,
tested, and either accepted (hopefully) or rejected (hopefully not).
Hopefully, that will still help with reviewing, but then if you commit
it, it'll probably go in as one stomping commit that changes the
world, or at most as two or three commits that are all still pretty
big. There are certainly cases where big stomping commits are good (I
have them in my own projects, too, and branches with long histories of
little dumb commits regularly get squashed and rebased before merging)
but I think it would be nice to have other options.
(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.)
...Robert