Hi,
Tom Lane wrote:
> How robust is git about dealing with whitespace changes,
> nearby variable renamings, and such?
Monotone tracks changes line by line. I'm not sure about git. Kdiff3,
which is used to do the manual merge, if necessary, uses some finer
grained method, AFAIK.
However, there's no special whitespace treatment. Nor anything remotely
as clever as "nearby variable renaming". There's no such magic, the
developer still needs to tell the tool what he wants.
However, I'd argue that monotone (as well as git) do an incredible job
at "remembering" these decisions and merges, so you never need to do a
manual merge twice. (Which I remember doing a lot with diff/patch, quilt
or subversion).
> 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?
I've given that patch a try under monotone (just because I happen to
know that a lot better). The results should be the same as with git.
I've started with the patch against 7.4 (which I know doesn't resemble
the current workflow, but is sufficient for testing merging
capabilities). Merging that to 8.0 worked without any conflicts.
Although the result then differed from Andrew's work in that the
variable dummy_perl_env is declared after the "#ifdef WIN32" block as
opposed to before in 7.4. The addition in the comment ("notably on
Windows") of course also didn't appear automatically.
It merged from 8.0 to 8.1 without any conflicts, results were equal.
Merging from 8.1 to 8.2 resulted in one merge conflict, because of the
additional condition ('if (interp_state == INTERP_NONE)') that got added
between 8.1 and 8.2.
Merging from 8.2 to 8.3 and then to HEAD as well was conflict free
again. The results differ in whitespace changes exclusively.
So, three out of the five merges would have been equally perfect with
automatic merging, while requiring only one single command, which could
even be scripted, because it remains the same over time, i.e. for
monotone it was something similar to:
mtn propagate REL8_0_STABLE REL8_1_STABLE
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
