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

From: Junio C Hamano <gitster@pobox.com>
Date: May 11, 2013, 17:54 UTC
Message-ID: <7vmws1xv0b.fsf@alter.siamese.dyndns.org>
In-Reply-To: <cover.1368274689.git.john@keeping.me.uk>

John Keeping <john@keeping.me.uk> writes:

Show 7 quoted lines

> 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.

Show 17 quoted lines

> 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".

> 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?

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