Andrew Dunstan <andrew@dunslane.net> writes:
> [ most of a good summary omitted ]
> ... Even fairly trivial patches can suffer
> from this: the pretty small plperl fixes I applied yesterday and the day
> before, required adjustment going from one branch to the previous one in
> about three out of five back branch cases. Sometimes these adjustments
> are small, sometimes they are quite large. So the idea that we can just
> create a fix on say, the 7.4 branch, and then just merge it forward
> nicely, is just fanciful in most cases, as well as being contrary to our
> methods of work.
I have heard it claimed that git is more intelligent than plain
diff/patch and could successfully merge patches in cases that currently
require manual adjustment of the sort Andrew describes. If that's
really true to any significant extent, then it could represent a benefit
large enough to persuade us to alter work flows (at least for simple
patches that don't require significant rethinking across branches).
However, I have yet to see any actual *evidence* in support of this
claim. How robust is git about dealing with whitespace changes,
nearby variable renamings, and such?
Andrew's plperl patches would be an excellent small test case. Anybody
want to try them against the experimental git repository and see if git
does any better than plain patch?
regards, tom lane
