On Fri, Apr 16, 2021 at 5:45 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Jerry Zhang <jerry@xxxxxxxxxx> writes:
>
> > Add the --exclude-path-first-parent flag,
> > which works similarly to --first-parent,
> > but affects only the graph traversal for
> > the set of commits being excluded.
> >
> > -A-------E-HEAD
> > \ /
> > B-C-D
> >
> > In this example, the goal is to return the
> > set {B, C, D} which represents a working
> > branch that has been merged into main branch
> > E. `git rev-list D ^E` will end up returning
> > no commits since the exclude path eliminates
> > D and its ancestors.
> > `git rev-list --exclude-path-first-parent D ^E`
> > however will return {B, C, D} as desired.
>
> It is not clera why you want to have this, instead of doing a more
> obvious "D..E^". Even better is "E^..E", which is often what you
> want when viewing a history like my 'seen' that is a straight-line
> into which tips of branches are merged.
My motivation is to find the point at which a release branch forked off from
a main branch, even though the release branch could have been merged
into the main branch multiple times since it was forked off.
If we add another merge from release to main, it will be more clear
that those give different results:
-A-------E-F-main
\ / /
B-C-D-release
`git rev-list --exclude-path-first-parent release ^main` returns {B, C, D}.
I've added commit F to show that we don't necessarily have info on E,
there could be many commits between it and the tip of main.
`git rev-list E^..E` returns {E, D} only, it depends on us knowing E and
loses all the commits after a merge from release to main.
I could do `git rev-parse (git rev-list --first-parent main
^release)^` and I'd get
A, but then I have to run `git rev-list D ^A` to get the set {B, C, D},
whereas the --exclude-path-first-parent invocation gives exactly
what I want in one invocation. I'm sure there's more use-cases
I'm not able to think of.
>
> E^..E (or doing the same for any commit on the mainline in such a
> history whose first-parent chain solely consists of merges) would
> show the list of the commits that came from the side branch that was
> merged, plus the merge commit, where the committer who created a
> merge would hava a chance to give a summary of what happened on the
> side branch.
