Re: [RFC/PATCH 0/2] merge-base: add --merge-child option

[John Keeping <john@keeping.me.uk>]

On Sat, May 11, 2013 at 10:54:12AM -0700, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
> 
> > This is helpful when examining branches with disjoint roots, for example
> > because one is periodically merged into a subtree of the other.
> >
> > With the --merge-child option, "git merge-base" will print a
> > first-parent ancestor of the first revision given, where the commit
> > printed is either a merge-base of the supplied revisions or a merge for
> > which one of its parents (not the first) is a merge-base.
> 
> The above two doe snot connect at least to me.  The second paragraph
> seems to describe how this mysterious mode decides its output to a
> sufficient detail, but what the output _means_, and it is unclear
> how it relates to gitk/git-gui style merges.
> 
> > For example, given the history:
> >
> >         A---C---G
> >              \
> >         B-----D---F
> >          \
> >           E
> >
> > we have:
> > ...
> >         $ git log --left-right F...E --not $(git merge-base --merge-child F E)
> >         < F
> >         > E
> >
> > The git-log case is useful because it allows us to limit the range of
> > commits that we are examining for patch-identical changes when using
> > --cherry.
> 
> Hmph, is this reinventing ancestry-path in a different way?  At the
> low level machinery, you are finding D to show only F and E, and
> your goal seems to be to ignore the side ancestry A--C--G, but it is
> not clear if you prefer "E D F"(which would be what F...E would give
> in a history limited to ancestry-path, ignoring C) over "E F".

I hadn't considered ancestry-path, but I don't think it does what I
want.  What I want if for LEFT to be B--D--F and RIGHT to be B--E,
ignoring A--C--G because I know that none of those are patch identical
to anything in B--E.

So what I want is more descendant-path than ancestry path in that I
don't want anything that isn't a descendant of the merge base of the
supplied arguments.

> > For example with git-gui in git.git I know that anything
> > before the last merge of git-gui is not interesting:
> 
> Can this be extended to find the second last such merge?  Or is the
> last one always special?

In this implementation it only finds the last one because that's where
the merge base is.

> Still skeptical, but I'll let people discuss it during the feature
> freeze ;-).

I'm not convinced this is easy to explain myself, which may make it a
bad idea.  Perhaps a --descendant-path argument to git-log is a better
way to help with this case.