"Philip Oakley" <philipoak...@iee.org> writes:
> From: "Junio C Hamano" <gits...@pobox.com>
>> "Philip Oakley" <philipoak...@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...