On Fri, Jun 5, 2009 at 9:38 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> "Markus Wanner" <markus@bluegap.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