On Thu, Jun 24, 2010 at 4:31 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Heh, this is a totally different operation to compare the tree before and
> after the merge.
>
> What "log merge^..merge^2" does is to list the commits we merged from the
> point of view of the person who did the merge. I haven't found the need
> for a short-cut for that myself, but in any case, I think such a feature
> belongs less to "show" (which is about "inspecting a single object") than
> to "log" (which is about "give me the sequence").
>
> You may want to look into merge.log variable if you find yourself wanting
> to do that often with your history, though.
Familiar with that and sadly insufficient. My merges often contain
100+ commits which is beyond what merge.log truncates. But more
importantly, I'm often inspecting the commits:
git log ..MERGE_HEAD -Scontent_to_watch_out_for
git log ..MERGE_HEAD -- /path/to/watch/out/for
etc. But sometimes I have to do this type of inspection after the
fact, which is what leads to the merge^..merge^2.
Perhaps the right place for such syntactic sugar would be in
rev-parse. Something like:
o A suffix ^{m..n} (i.e. rev^{1..2}) when rev is a merge commit
expands to rev^m..rev^n and is only valid in contexts that take a
range. 'm' and 'n' may be left out in which case they are assume to be
1 and 2. (i.e rev^{..} is rev^1..rev^2).
But I haven't entirely thought this through. :-)
j.
--
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