Alex Hunsaker <bada...@gmail.com> writes: > How exactly patches get applied into back branches? Has that been > spelled out somewhere? There are a lot of ways to do it. For > instance git.git seems to apply the patch to the earliest branch first > and then merge it on up so that everything can share the same > commit/hash. That looks like a royal PITA to me, and I assume the > plan is to just cherry-pick commits back. As long as we use git > cherry-pick -x, I agree with Magnus, it should be fairly easy to write > a short script to do it. II'll even volunteer if the above is > basically the only requirement :-).
There was discussion about that before, but I don't know whether we really have a solution that will work comfortably. A couple of comments: * My practice has always been to develop a fix in HEAD first and then work backwards. I'm going to resist any tool that tries to force me to do it the other way. There are a couple of reasons for that: one, I'm generally more familiar with HEAD, and two, I want HEAD to have the cleanest solution. If you do an old branch first, you'll probably come up with a solution that is good for that branch but could be improved in newer ones, eg by using some subroutine or facility that doesn't exist earlier. Forward-patching won't encourage you to find that. * My experience is that a patch that has to go back more than one or two branches is almost never exactly the same on each branch, even without any of the non-trivial changes suggested above. We constantly do things like rearrange the arguments of some function that's used everywhere. So "patch" is definitely not smart enough to back-patch the fixes by itself. Maybe git will be a lot smarter but I'm not expecting miracles. Anything that is based on "same hash" is pretty much guaranteed to not do what I need. I'd be satisfied with a tool that merges commit reports if they have the same log message and occur at approximately the same time, which is the heuristic that cvs2cl uses. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers