On Wed, Jul 15, 2015 at 9:29 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> I would think "git log -p" that implies "--cc" would be a good
> change, as long as there is an easy escape hatch to let us do what
> we have to do with a rather lengthy "git log -p --first-parent -m"
> (i.e. show the change relative to its first parent while traversing
> the first parent chain) today. Perhaps only when there is no
> explicit "-m" but "-p" is given, automatically enable "--cc", or
> something like that.
That's very close to what "git show" does through that magic
show_rev_tweak_rev() logic, with the crucial difference being that
"git show" is designed to always show the diff, so the "-p" is
implied.
That said, having thought about it more, I'm not entirely sure we can
do it. The big conceptual difference between "git log" and "git show"
is obviously that "git show" doesn't walk the revision list, and you
always explicitly say "show _this_ commit".
And that means that with "git show", you kind of _know_ that the
commit is relevant and interesting, in a way that "git log" does not.
So got "git show", it's very natural to say "show all the relevant
information", while for "git log" we did make the choice that maybe
commit diffs aren't relevant by default.
And the whole issue ends up boiling down to "maybe we picked the wrong
choice default". We default to that "ignore_merges = 1" behavior.
Now, we defaulted to ignoring merge diffs because long long ago, in a
galaxy far away, we didn't have a great way to show the diffs. The
whole "--cc" option goes back to January -06 and commit d8f4790e6fe7
("diff-tree --cc: denser combined diff output for a merge commit") .
And before that option - so for about 8 months - we had no good way to
show the diffs of merges in a good dense way.
So the whole "don't show diffs for merges by default" actually made a
lot of sense originally, because our merge diffs were not very useful.
But that does mean that if we now enable "--cc" by default when you
ask for diffs, we have no good way to _disable_ it. We picked "disable
by default", and "-m" means "enable merge diffs". And that made sense
back in 2005 because we really wanted to disable the whole "show diffs
for merges" thing.
Of course, you can use "--no-merges" to basically not show merges at
all, so maybe that's ok. But I get the feeling that if we make "-p"
imply "--cc", we should probably add a "--no-merge-diff" option too to
replace the (broken) "-m" flag properly. And I'm a tiny bit worried
that it might break some script (although I'm really not seeing
how/why you'd script "git log -p" output and not want to get a --cc
patch for a merge).
And "-m"? We should probably get rid of it. The diffs we get for
merges when "-c" or "--cc" isn't given are _not_ useful. The original
non-combined diff format was really just useful for showing that
"yeah, we have multiple parents, and they are different in all these
ways". So there is no actual valid use for "-m" that I can imagine.
It's simply just an odd historical artifact from a time when we didn't
know how to show merges.
Linus
--
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