Re: git log fails to show all changes for a file

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 15, 2015, 17:13 UTC
Message-ID: <CA+55aFy8urE+0w7mfgywcAnyoUu+6LMz-GGaOrUQYJ59gT9FfA@mail.gmail.com>
In-Reply-To: <xmqq8uahxu3e.fsf@gitster.dls.corp.google.com>

On Wed, Jul 15, 2015 at 9:29 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

>
> 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