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

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@linux-foundation.org> 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