Robert Haas <robertmhaas@gmail.com> writes:
> 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.
"Commit to each branch separately" is surely the closest analog to what
we have done historically. What I'm trying to understand is whether
there's an easy variant on that that'd expose the related-ness of the
patch versions in a way git understands, hopefully giving us more
ability to leverage git's capabilities in future.
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.
regards, tom lane