On Sat, May 11, 2013 at 10:54:12AM -0700, Junio C Hamano wrote:
> 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:
> > 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
> > 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.
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