Re: Are --first-parent and --ancestry-path compatible rev-list options?

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 1, 2016, 17:32 UTC
Message-ID: <xmqq8tvby19a.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CD6AE25418644EB688D4488F8AB40155@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 27 quoted lines

> From: "Junio C Hamano" <gitster@pobox.com>
>> "Philip Oakley" <philipoakley@iee.org> writes:
>>
>>> The commit graph. We are looking for F based on knowing J.
>>>
>>> . A - B - C - D -- E -- F -- G - H    <-first parent, --merges (C,F,H)
>>> .  \  |  /    \        /    /
>>> .   ----Z     |       /    /
>>> .     |       |       |   /
>>> .      \       \     /   /
>>> .       I -[J]- K - L - M             <-since J, children of J
>>> .        \         /
>>> .         N - O - P
>>
>> I think these two operations are fundamentally incompatible.
>
> If I run them independently, they both find the desired INTERESTED
> commit, hence the expectation that together they will still find that
> commit as an intersection between the two sets.
>
>>
>> Because the first-parent traversal is what the name says, i.e.,
>> forbids the positive side of revision traversal to stray into side
>> branches, the positive side of a traversal that begins at H will not
>> see M, L and K.
>
> But it does see F the ultimately desired commit.

You are doing --merges --first-parent, right? Traversing only the first-parent chain on the positive side, while excluding J's ancestor by traversing the negative side without being limited to the first-parent chain, would paint B and its ancestors as uninteresting on the first-parent chain, so among H, G, F, E, D and C, which are the survivors on the first-parent chain that are still not UNINTERESTIN, the last one you would find that is a merge is F.

So I do not see any room for "But" to come in here...