"Philip Oakley" <philipoakley@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html