Our branch history looked something like the following:
B---C
/ \
A---D---E---H
\ /
F---G
In commit D a few lines were added to a file, and then in commit G the same
lines were removed. When branches E and G were merged, those lines unexpectedly
re-appeared in the merge commit (H), even though no other commits had touched
that file.
I think I understand why this happened: git-merge-base reports that the common
ancestor for E and G is A. Since those lines don't appear in that file in
commits A or G, git-merge assumes that they were added independently on branch
E, so it decides to keep the lines in the merged result.
This merge problem arises because although A is the most recent common ancestor
of branches E and G in general, it is *not* the most recent common ancestor as
far as that single file is concerned. The most recent common ancestor for that
particular file is commit D.
This is worrisome because I imagine the converse will also be a potential
problem: lines are removed in commit D, and then re-added in commit G, and they
will unexpectedly disappear in the merge (H). So my question is whether this is
a bug in git (ie, shouldn't git be considering independent common ancestors for
each file that is merged)? This doesn't seem like a particularly unique or rare
scenario - how is everyone else preventing these kinds of problems?
Dale
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html