"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