Re: Unexpected merge results in git-svn repo

From: Jon Seymour <jon.seymour@gmail.com>
Date: Jul 31, 2013, 11:51 UTC
Message-ID: <CAH3AnrqAXhNEnKFxta5TGHwus+Sck1moEZe5V1J_9k7ZHQuW=A@mail.gmail.com>
In-Reply-To: <CAH3AnrqmFJxuy7PyJZS83VEwzrQB+mA5Frttd5fzKBhpZGP4Eg@mail.gmail.com>

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.seymour@gmail.com> wrote:

Show 24 quoted lines

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