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 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
