Re: git log -p unexpected behaviour - security risk?

From: Thomas Rast <trast@inf.ethz.ch>
Date: Apr 21, 2013, 15:56 UTC
Message-ID: <8738ujubbs.fsf@hexa.v.cablecom.net>
In-Reply-To: <CAHQ6N+rXE42NOyQPfLiDN8jYfL8w06hEE5MFLeFNxMR4ORD0aw@mail.gmail.com>

John Tapsell <johnflux@gmail.com> writes:

Show 10 quoted lines

> On 21 April 2013 11:21, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>> A merge can completely
>> undo important changes made in a side branch and "-c" and "--cc" will
>> not show it.
>
> Wait, what?  This is getting even worse then!  Can you expand on this please?
>
> And then how do I show all of these important changes with a git log -p ?
> Or is it impossible to get a sane output?

It pretty much by definition does not show changes if the merge picks one side unchanged:

 -c
     [...] lists only files which were modified from all parents.

 --cc
     This flag implies the -c option and further compresses the patch
     output [...]

On top of that, the default history simplification when you specify a pathspec will only walk the (or any one) unchanged side of such a merge, so if you filter for a file you wouldn't even find the offending commit further back in history.

I don't think this can be improved easily with the current one-pass[1] history/diff generation. To know what the merge *should* have done, you'd need to somehow get an idea what parts of the resulting files should be affected, which AFAICS boils down to redoing the merge. And to do that, you need to scan history so far that you can compute the merge-bases. Not to mention that redoing all merges while walking history is somewhat expensive.

You could hack up a script that does the verification manually, by actually running a merge and comparing the result with what the merge gave you. But it's not something that you would want to run by default.

[1] some things like --simplify-merges are actually another pass, but the default is to generate everything -- including diffs -- as we go.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch