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

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.  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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to