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

Linus Torvalds [off-list ref] writes:

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

I agree with most of your analysis of the history, but not with "-m"
(rather, a part of what "-m" does).

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.

When combined with "--first-parent" it is a way to view what the
merge brought in from a side branch.

    $ git log --first-parent -m -p ko/master..master

is something I do every time I merge a batch of topics to the
'master' branch (where ko/master keeps track of what was pushed
to k.org the last time).

The fact that "-m" shows diffs with each and every parent is an odd
historical behaviour, and the only justification for it is that
people might want to view differences with second and later parents,
which is weak, and one way to allow them to view differences with
later parents is to show all (and force people to skip them in
normal use case), which is even weaker.

So to be constructive and to pu a different proposal on the table,
how about aiming for this end-game state?

 * When '-p' is given, we show only diff with first-parent by
   default, regardless of the traversal (i.e. --first-parent option
   currently controls both traversal and patch display, but in the
   new world order, it reverts back to purely a traversal option).

 * We could allow you to say '-p -m2' to get second-parent diff for
   merges, but I do not think we should bother, for at least two
   reasons.  It opens a can of worms, like "what should '-p -m4' to
   for a two-parent merge?"  Also "log" unlike "show" is about many
   commits, and I do not think of a reason why you would want a
   series of diff between the side-branch tip and the result.  '-m2'
   would only be useful for commits that was made by mistake,
   merging the trunk into a side branch, swapping the
   first-parenthood, which ought to be rare.

 * If somebody wants to omit patch for merges, while still showing
   the merge log, use '-p --no-show-merge-diff'.

 * When people want '--cc' or '-c', they can with 'log -p --cc',
   just like today.  We might want to make '--cc' imply '-p', but I
   vaguely recall some discussion against this [*2*].

Transition plan is a separate matter.


[Footnotes]

*1* With modern Git if you were pushing only to a single
    destination, you could say master@{push} instead, but I do not
    have remote.origin in my repository and push to multiple places,
    so master@{push} does not resolve ;-)

*2* http://thread.gmane.org/gmane.comp.version-control.git/215341/focus=215470

On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano [off-list ref] wrote:

 * When '-p' is given, we show only diff with first-parent by
   default, regardless of the traversal (i.e. --first-parent option
   currently controls both traversal and patch display, but in the
   new world order, it reverts back to purely a traversal option).

So this is a suggested change to "-p -m" behavior?

Yes, that sounds sane. The current "-p -m" behavior is not useful at all.

So if I understand rightly, we'd have:

 "-p" would be what is currently  "-p --cc"
 "-p -m" would be what is currently "-p --first-parent"
 "-p --no-show-merge-diffs" would be what is currently "-p"

and the rationale would be that

 (a) the current "-p" is hiding things, and while you can add "--cc",
that requires that you really understand what is being hidden, which
is a bad default (the complaint that started this discussion)

 (b) the current "-p -m" is useless crazy stuff, and you'd rather use
it for something that you actually find very common and useful

If so, I agree entirely.

              Linus