From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 14 Jul 2015 19:16:48 GMT
Subject: Re: git log fails to show all changes for a file
Message-ID: <CA+55aFzPvwAghGtA-WH8i1PcNe55XORokaXF9hNu7OUXBx++6Q@mail.gmail.com>
In-Reply-To: <20150714075955.GA24577@aepfle.de>

On Tue, Jul 14, 2015 at 12:59 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Jul 14, John Keeping wrote:
>
>> It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),

That's not an evil merge. That's just a regular merge. One side had
changed the argument to "const":

 - 1b9d48f2a579 ("hyper-v: make uuid_le const")

while the other side had renamed the function and added an argument,
and changed the return type:

 - d3ba720dd58c ("Drivers: hv: Eliminate the channel spinlock in the
callback path")

an "evil merge" is something that makes changes that came from neither
side and aren't actually resolving a conflict.

That said, I do wonder if we should just make "-p" imply "--cc". Right
now we have the kind of odd situation that "git log -p" doesn't show
merge patches, but "git show <cmit>" does show them. And you kind of
have to know a lot about git to know the "--cc" option.

In fact, that "git show" behavior really is very subtle, but very
useful. It comes from show_rev_tweak_rev(), which is a magic git-show
thing.

               Linus