Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
--
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