Tom Lane wrote:
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
Any revision control system should be able to do better than diff/patch
as these systems have more information available to them. Normal GIT
uses the relatively common 3-way merge based upon the most recent common
ancestor algorithm. Assuming there is a most recent common ancestor that
isn't "file creation", it will have a better chance of doing the right
thing.
Systems such as ClearCase have had these capabilities for a long time.
The difference with distributed version control systems is that they
absolutely must work well, as every user has their own repository, and
every repository represents a branch, therefore each user of the system
is working on a different branch. The need for reliable merges goes up
under a distributed version control system.
Not to say GIT is truly best-in-class here, but it definitely has
motivation to be and benefit of being better than diff/patch.
These sorts of tools usually work with another tool such as kdiff3 to
allow for only the conflicts the be resolved. If you set it up properly,
you can have the automatic merges completely successful, and kdiff3 or
similar can present you a graphical interface that allow you to identify
and resolve the conflicts that require help. I've used these sorts of
tools long enough to completely take them for granted now, and it feels
painful to go back to anything more primitive.
Cheers,
mark
--
Mark Mielke <m...@mielke.cc>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
