Re: potential improvement to 'git log' with a range
- From
Jay Soffian <jaysoffian@gmail.com>
- Date
- Jun 24, 2010, 22:49 UTC
- Message-ID
- <AANLkTiloAQmjAMVOROzBHkLAAIDj-KNFNcfXC9pdwDf5@mail.gmail.com>
- In-Reply-To
- <7v8w64cguk.fsf@alter.siamese.dyndns.org>
On Thu, Jun 24, 2010 at 4:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> 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.