Re: PostgreSQL Developer meeting minutes up

"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?
        regards, tom lane