Re: potential improvement to 'git log' with a range

[Jay Soffian <jaysoffian@gmail.com>]

On Thu, Jun 24, 2010 at 4:31 PM, Junio C Hamano <gitster@pobox.com> 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.