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

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

Jeff King <peff@peff.net> writes:

> On Wed, Jul 15, 2015 at 11:17:50AM -0700, Junio C Hamano wrote:
>
>> > So this is a suggested change to "-p -m" behavior?
>> 
>> Not really.  This is a suggested behaviour for "git log -p"; I
>> wasn't very enthused by the idea to turn --cc when user said -p
>> without telling them what we are doing.  In other words, if the
>> users want combined, they should say --cc (and they will get a
>> single-parent patch for non-merges with --cc) so there is no reason
>> not to do this, as long as we fix --cc so that "git log --cc"
>> implies "git log --cc -p".
>
> Like you, I frequently use "--first-parent -m". If I understand your
> proposal, a regular "git log" would have the first-parent-diff behavior
> of those options, but still traverse other parents.
>
> One oddity of that proposal is that the user ends up seeing any given
> change on a side-branch _twice_. Once in the original commit that
> introduced it, and once in the merge of the branch. And commit-selection
> tools like "git log -Ssome_code" will select both, too, and they'll see
> the merge commit along with the original. I can't decide if that's a
> good thing or not.

Hmm, you are right.  That may be a problem, and Linus's makes tons
of practical sense (especially for us experienced Git users).

It just is that '-p', that clearly stands for 'patch' but does more
than 'patch' to produce something that cannot be fed to 'apply' by
defaulting to '--cc', makes me hesitate.  By making it a lot more
convenient for experienced people who understand these issues, I
have this suspicion that it would make the options less orthgonal
and harder to explain to new people.