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

On Sat, May 11, 2013 at 10:54:12AM -0700, Junio C Hamano wrote:

John Keeping [off-list ref] writes:

quoted

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.

quoted

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.

quoted

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.