John Keeping <j...@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:
> 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
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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html