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