Re: [PATCH 00/48] Handling more corner cases in merge-recursive.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Unfortunately I seem to have found a regression that manifests in the real
life.

When this series is merged to 'next', it mismerges a trivial renamed path.
A sample commit to reproduce is 2d11f21c3, which is a merge between
28b9264dd6 and 5b42477b59.  Check out the former and try to merge in the
latter.

The merge base of these two commits is 2cfe8a68ccb (no criss-cross).

One branch (current one, 28b9264dd6) does not have that path, but it does
have t/t4037-whitespace-status.sh:

    $ git ls-tree 28b9264dd6 t/t4037-whitespace-status.sh
    100755 blob 3c728a3ebf9ce52e5c24c81525d5cb749cfb2957 t/t4037-whitespace-status.sh

What happened to that path on the current branch is this:

    $ git log -m -M --raw --pretty=short 2cfe8a68ccb..28b9264dd6 -- \
      t/t40{37,40}-whitespace-status.sh
    commit af7b41c923677ff9291bab56ec7069922e37453b
    Author: Jeff King <peff@xxxxxxxx>

        diff_tree: disable QUICK optimization with diff filter

    :100755 100755 abc4934... 3c728a3... M  t/t4037-whitespace-status.sh

In other words, we had t4037, and we have t4037 but we updated its
contents from abc4934 to 3c728a3.

Running "log -m -M --raw --pretty=short 2cfe8a68ccb..5b42477b59" shows
that the merged branch (5b42477b59) has renamed t4037 to t4040 at
0e098b6d:

    commit 0e098b6d79fbcab763874f2b6fde5aa82144d150
    Author: Johannes Sixt <j6t@xxxxxxxx>

        Make test case number unique

    :100755 100755 a30b03b... a30b03b... R100 t/t4037-whitespace-status.sh    t/t4040-wh..

This commit is on a side-branch that has not been merged at the merge base
2cfe8a68ccb; its contents a30b03b is older than what 2cfe8a68ccb has, and
was updated by 2cfe8a68ccb to abc4934.

Another merge after this commit updated it at 7d0cf357:

    commit 7d0cf357a31cc8a442342696788d776265482ce9 (from 98b256bd...)
    Merge: 98b256b 2cfe8a6
    Author: Junio C Hamano <gitster@xxxxxxxxx>

        Merge branch 'jc/maint-diff-q-filter'

    :100755 100755 a30b03b... abc4934... M  t/t4040-whitespace-status.sh

This abc4934 is the same contents as the merge base had at t4037.

So this is an "our side kept t4037 and updated its contents from abc4934
to 3c728a3, while the other side renamed t4037 to t4040 and kept its
contents as abc4934". We should merge this as structural change "our side
left it untouched, their side renamed, so take the rename without
conflict" and content level change "our side updated but their side left
it untouched, so take our modification without conflict".

In other words, in the result, we should have 3c728a3 at t4040, and that
indeed is what we got in the recorded history:

    $ git ls-tree 2d11f21c3 -- t/t4040-whitespace-status.sh
    100755 blob 3c728a3ebf9ce52e5c24c81525d5cb749cfb2957 t/t4040-whitespace-status.sh

However, the merge retried with this series cleanly resolves the path, but
with wrong contents:

    $ git checkout 28b9264dd6
    $ git merge 5b42477b59
    $ git ls-files -s t/t4040-whitespace-status.sh
    100755 abc49348b196cf0fec232b6f2399356e4fe324d5 0 t/t4040-whitespace-status.sh

Correct answer should be:

    $ git ls-files -s t/t4040-whitespace-status.sh
    100755 3c728a3ebf9ce52e5c24c81525d5cb749cfb2957 0 t/t4040-whitespace-status.sh

I am rewinding today's integration of 'next' to unmerge this topic
now. :-(...


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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]