Visualizing merge conflicts after the fact (using kdiff3)

> I'm running 1.9.5.msysgit.1, but this is a general git question...
> 
> Upon returning from a vacation, I was looking at what people had been
> up to, and discovered on merge in which a colleague had resolved a merge
> incorrectly.  It turns out that he has pushed *many* merges over the past
> year which had conflicts in my code, and now I don't trust any of them.
> 
> So naturally I want to check each of them for correctness.
> 
> I know about "git log -p -cc SHA -- path", but it really doesn't
> show just the conflicts so there's just too much noise in that output.
> 
> I use kdiff3 to resolve conflicts, so I'm looking for a way to
> visualize these already-resolved conflicts with that tool.
> As I said, there are many merges, so the prospect of checking
> out each sha, doing the merge, and then comparing the results
> is completely untenable.
> 
> Can anyone help?  Surely other people have wanted to review how
> conflicts were resolved w/out looking at the noise of unconflicted
> changes, right?

> Hi Eric,
> 
> On 2015-06-16 03:17, Eric Raible wrote:
>> I'm running 1.9.5.msysgit.1, but this is a general git question...
>>
>> Upon returning from a vacation, I was looking at what people had been
>> up to, and discovered on merge in which a colleague had resolved a merge
>> incorrectly.  It turns out that he has pushed *many* merges over the past
>> year which had conflicts in my code, and now I don't trust any of them.
>>
>> So naturally I want to check each of them for correctness.
>>
>> I know about "git log -p -cc SHA -- path", but it really doesn't
>> show just the conflicts so there's just too much noise in that output.
>>
>> I use kdiff3 to resolve conflicts, so I'm looking for a way to
>> visualize these already-resolved conflicts with that tool.
>> As I said, there are many merges, so the prospect of checking
>> out each sha, doing the merge, and then comparing the results
>> is completely untenable.
>>
>> Can anyone help?  Surely other people have wanted to review how
>> conflicts were resolved w/out looking at the noise of unconflicted
>> changes, right?
> 
> If I was walking in your shoes, I would essentially recreate the merge conflicts and then use "git diff <merge-commit>" with the resolved merge in your current history.
> 
> Something like this:
> 
> ```bash
> mergecommit=$1
> 
> # probably should verify that the working directory is clean, yadda yadda
> 
> # recreate merge conflicts on an unnamed branch (Git speak: detached HEAD)
> git checkout $mergecommit^
> git merge $mergecommit^2 ||
> die "This merge did not have any problem!"
> 
> # compare to the actual resolution as per the merge commit
> git diff $mergecommit
> ```
> 
> To list all the merge commits in the current branch, I would use the command-line:
> 
> ```bash
> git rev-list --author="My Colleague" --parents HEAD |
> sed -n 's/ .* .*//p'
> ```
> 
> (i.e. listing all the commits with their parents, then filtering just the ones having more than one parent, which would include octopus merges if your history has them.)
> 
> Hopefully this gives you good ideas how to proceed.
> 
> Ciao,
> Johannes
> .

> Hi Eric,
> 
> On 2015-06-16 03:17, Eric Raible wrote:
>> I'm running 1.9.5.msysgit.1, but this is a general git question...
>>
>> Upon returning from a vacation, I was looking at what people had been
>> up to, and discovered on merge in which a colleague had resolved a merge
>> incorrectly.  It turns out that he has pushed *many* merges over the past
>> year which had conflicts in my code, and now I don't trust any of them.
>>
>> So naturally I want to check each of them for correctness.
>>
>> I know about "git log -p -cc SHA -- path", but it really doesn't
>> show just the conflicts so there's just too much noise in that output.
>>
>> I use kdiff3 to resolve conflicts, so I'm looking for a way to
>> visualize these already-resolved conflicts with that tool.
>> As I said, there are many merges, so the prospect of checking
>> out each sha, doing the merge, and then comparing the results
>> is completely untenable.
>>
>> Can anyone help?  Surely other people have wanted to review how
>> conflicts were resolved w/out looking at the noise of unconflicted
>> changes, right?
> 
> If I was walking in your shoes, I would essentially recreate the merge conflicts and then use "git diff <merge-commit>" with the resolved merge in your current history.
> 
> Something like this:
> 
> ```bash
> mergecommit=$1
> 
> # probably should verify that the working directory is clean, yadda yadda
> 
> # recreate merge conflicts on an unnamed branch (Git speak: detached HEAD)
> git checkout $mergecommit^
> git merge $mergecommit^2 ||
> die "This merge did not have any problem!"
> 
> # compare to the actual resolution as per the merge commit
> git diff $mergecommit
> ```

> To list all the merge commits in the current branch, I would use the command-line:
> 
> ```bash
> git rev-list --author="My Colleague" --parents HEAD |
> sed -n 's/ .* .*//p'
> ```
> 
> (i.e. listing all the commits with their parents, then filtering just the ones having more than one parent, which would include octopus merges if your history has them.)

> 
> Hopefully this gives you good ideas how to proceed.
> 
> Ciao,
> Johannes
> 

> Johannes Schindelin venit, vidit, dixit 16.06.2015 11:43:
>
>> To list all the merge commits in the current branch, I would use the command-line:
>>
>> ```bash
>> git rev-list --author="My Colleague" --parents HEAD |
>> sed -n 's/ .* .*//p'
>> ```
>>
>> (i.e. listing all the commits with their parents, then filtering just the ones having more than one parent, which would include octopus merges if your history has them.)
> 
> :)
> 
> "--merges" (aka "--min-parents=2") is your friend here.

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> This type of request comes up often (for a reason). I'm wondering
>> whether we could support it more systematically, either by exposing the
>> steps above as a command, or by storing the unresolved merge somewhere
>> (leveraging stash or rerere).
> 
> Perhaps 'tr/remerge-diff' (on 'pu') is of interest?
> 

> Junio C Hamano venit, vidit, dixit 18.06.2015 17:57:
>> 
>> Perhaps 'tr/remerge-diff' (on 'pu') is of interest?
>
> I haven't reviewed remerge-diff but merged it on top of my own local
> additions and ran the full test suite successfully. Any big blocker to
> watch out for?