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

From: Philip Oakley <philipoakley@iee.org>
Date: Aug 27, 2016, 11:04 UTC
Message-ID: <CD6AE25418644EB688D4488F8AB40155@PhilipOakley>
In-Reply-To: <xmqqfuprdtwh.fsf@gitster.mtv.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>

Show 14 quoted lines

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

Show 5 quoted lines

>
> 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. Philip@PhilipOakley MINGW32 /usr/src/test (master)

$ git log --oneline --first-parent --merges :/j..

d089efa g

ac811d4 f

1db59e5 c

Then we have:
--ancestry-path
    Limit the displayed commits to those directly on the ancestry chain 
between the "from" and "to" commits in the given commit range.

So one would expect, from a user viewepoint that this is commit selection, not internal algorithm implementation, that it would only list G and F, and the C would not be displayed.

Show 6 quoted lines

>  The negative side would traverse in the normal way
> to paint commits starting J and its ancestors as UNINTERESTING, so
> the traversal over the artificial "first-parent only" history, i.e.
> H, G, F, E, D, C, B, A would eventually stop before showing an
> ancestor of J.
>

> On the other hand, to compute the ancestry-path, you need to make a
> full traversal of the real history to find a subgraph J..H and then
> post-process it to cull paths that do not contain J.

The culling order isn't clear. It's easy to expect that --first parent is a cull. The documentation implies (to me) this different computation.

This explains why its happening, but it does feel rather contrary to user (rather than developer) expectation. It's the confusion between traversal limiting and marking a commit as Interesting (i.e. UNINTERSTING has two meanings which may not align when multiple options are given.)

It does seem odd that in the Git world, with its feature branch approach, that this hasn't come up before. I know that I haven't even bothered to try this 'search', and just use gitk to manually follow the breadcrumbs.

Perhaps a `--first-parent-ancestor` option to determine the places where a commit from a feature series was merged in to the mainline would be rather helpful.

> --

Philip