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.
Philip@PhilipOakley MINGW32 /usr/src/test (master)
$ git log --oneline --first-parent --merges :/j..
d089efa g
ac811d4 f
1db59e5 c
Then we have:
--ancestry-path
Limit the displayed commits to those directly on the ancestry chain
between the "from" and "to" commits in the given commit range.
So one would expect, from a user viewepoint that this is commit selection,
not internal algorithm implementation, that it would only list G and F, and
the C would not be displayed.
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.
The culling order isn't clear. It's easy to expect that --first parent is a
cull.
The documentation implies (to me) this different computation.
This explains why its happening, but it does feel rather contrary to user
(rather than developer) expectation. It's the confusion between traversal
limiting and marking a commit as Interesting (i.e. UNINTERSTING has two
meanings which may not align when multiple options are given.)
It does seem odd that in the Git world, with its feature branch approach,
that this hasn't come up before. I know that I haven't even bothered to try
this 'search', and just use gitk to manually follow the breadcrumbs.
Perhaps a `--first-parent-ancestor` option to determine the places where a
commit from a feature series was merged in to the mainline would be rather
helpful.
--
Philip
--
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