Re: Are --first-parent and --ancestry-path compatible rev-list options?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 26, 2016, 22:53 UTC
- Message-ID
- <xmqqfuprdtwh.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <2FA1998250474E76A386B82AD635E56A@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
Show 10 quoted lines
> 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.