From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Greg Stark <stark(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Developer meeting minutes up |
Date: | 2009-06-05 15:29:30 |
Message-ID: | 603c8f070906050829m1eaaa969tff7ca85d04018c5a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 5, 2009 at 9:38 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Markus Wanner" <markus(at)bluegap(dot)ch> writes:
>> Note that a requirement for daggy fixes is that "the bug is fixed
>> close to the point where it was introduced". So fixing it on the
>> oldest stable branch that introduced a bug instead of fixing it on
>> HEAD and then back-porting would certainly be a step into the right
>> direction.
>
> I think it's already been made crystal clear that the people who
> actually do this work don't do it that way, and are uninterested in
> allowing their tools to force them to do it that way. Patching from
> HEAD back works better for us for a number of reasons, the main one
> being that HEAD is the version of the code that's most "swapped into"
> our awareness.
>
> However, so long as we can have a separate working copy per branch,
> I see no problem with preparing all the versions of a patch and then
> committing them back-to-front. What I'm not clear about is the
> mechanics for doing that. Would someone explain exactly what the
> steps should be to produce the nicest-looking git history?
I'm sure someone is going to come in here and again recommend merging,
but I'm going to again recommend not merging. Cherry-picking is the
way to go here. Or just commit to each branch completely separately
with the same commit message; cherry-pick at least IMO is just a
convenience to help you attempt to apply the patch to a different
branch.
The way you're using commit messages to construct the release notes
really puts a limits on what the history has to look like. I think it
would be good to find a better way to generate release notes that
isn't quite so dependent on having a very tight history, but even if
we do that I think in this particular situation cherry-picking is
going to be less work for the committers than any of the other options
that have been proposed.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-05 15:37:53 | Re: PostgreSQL Developer meeting minutes up |
Previous Message | Dave Page | 2009-06-05 14:52:32 | Re: It's June 1; do you know where your release is? |