Re: Weird revision walk behaviour

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

 



On 23/05/2018 20:35, Jeff King wrote:
On Wed, May 23, 2018 at 01:32:46PM -0400, Jeff King wrote:

On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote:

   $ git log --oneline master..ba95710a3b -- ci/
   ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2


I keep some older builds around, and it does not reproduce with v1.6.6.3
(that's my usual goto for "old"). Bisecting turns up d0af663e42
(revision.c: Make --full-history consider more merges, 2013-05-16).  It
looks like an unintended change (the commit message claims that the
non-full-history case shouldn't be affected).
There's more discussion in the thread at:

   https://public-inbox.org/git/1366658602-12254-1-git-send-email-kevin@xxxxxxxxx/

I haven't absorbed it all yet, but I'm adding Junio to the cc.


In this case, we're hitting a merge commit which is not on master, but it has two parents which both are. Which, IIRC, means the merge commit is INTERESTING with two UNINTERESTING parents; and we are TREESAME to only one of them.

The commit changing the logic of TREESAME you identified believes that those TREESAME changes for merges which were intended to improve fuller history modes shouldn't affect the simple history "because partially TREESAME merges are turned into normal commits". Clearly that didn't happen here.

I think we need to look at why that isn't happening, and if it can be made to happen. The problem is that this commit is effectively the base of the graph - it's got a double-connection to the UNINTERESTING set, and maybe that prevented the simple history "follow 1 TREESAME" logic from kicking in. Maybe it won't follow 1 TREESAME to UNINTERESTING.

I know there were quite a few changes later in the series to try to reconcile the simple and full history, for the cases where the simple history takes a weird path because of its love of TREESAME parents, hiding evil merges. But I believe the simple history behaviour was supposed to remain as-is - take first TREESAME always.

Kevin





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

  Powered by Linux