"Philip Oakley" <philipoakley@xxxxxxx> writes: > From: "Junio C Hamano" <gitster@xxxxxxxxx> >> "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. > > 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...
