John Tapsell <johnflux@xxxxxxxxx> writes:
> On 21 April 2013 11:21, Jonathan Nieder <jrnieder@xxxxxxxxx> 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
--
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