Re: Weird revision walk behaviour

[Kevin Bracey <kevin@bracey.fi>]

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@bracey.fi/
>
> 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