To answer my own question... My issue turned to be caused by a bad graft in my repo (unfortunately, since hardened with filter-branch) that was making the commit that modified F on Y reachable from X. The graft was an (incorrectly executed) attempt to deal with the "3+ parent" problem that sometimes occurs when git-svn pulls merges back from SVN.
jon. On Wed, Jul 31, 2013 at 8:14 PM, Jon Seymour <jon.seym...@gmail.com> wrote: > I am getting some unexpected results from a merge and I'd like to > understand why. > > I have two commits X and Y that I want to merge. > > git merge-base X Y # yields B > git diff B X -- F # is empty > git diff B Y -- F # contains the change I want merged > git rev-list X ^B -- F # is empty > git rev-list Y ^B -- F # contains one commit > > git checkout X > git merge Y > > fails with fixable merge conflicts on other files, but uses X's copy > of F instead of Y's. > > I was expecting it to use Y's copy of F, since only Y has modified F since B. > > What could cause this? > > BTW: I am using a git-svn repo that does have some 4+ parent merges in it. > > jon. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
