Re: Visualizing merge conflicts after the fact (using kdiff3)
On 16.06.2015 03:17, Eric Raible wrote: > So naturally I want to check each of them for correctness. Sorry for joining this thread so late, I only come to know about it from the draft of the upcoming Git Rev News 5 [1]. A while ago Robin Green was asking a very similar question on StackOverflow [2], and I came up with a script called "git-show-merge-resolution.sh" [3]. Maybe that's something you're interested in, too. [1] https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-5.md#support [2] stackoverflow.com/questions/24958182/kdiff3-to-code-review-merge-commit/24958228 [3] https://github.com/sschuberth/dev-scripts/blob/master/git/git-show-merge-resolution.sh -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Visualizing merge conflicts after the fact (using kdiff3)
Michael J Gruber writes: > 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? "What's cooking" report marks it as "Waiting for a reroll. ($gmane/256591)." So http://thread.gmane.org/gmane.comp.version-control.git/256591 would be the first place to revisit. -- To unsubscribe from this list: send the line "unsubscribe git" in
Re: Visualizing merge conflicts after the fact (using kdiff3)
Junio C Hamano venit, vidit, dixit 18.06.2015 17:57: > Michael J Gruber 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? > Ingenious! To me, this seems to be the most useful view if you want to understand a merge just from the parents and the merge commit. Since you would use that for individual commits only, the cpu cycles are well spent. As and added benefit, tr/remerge-diff merges to current next with conflicts (oid...) so that you get to test it on its own merge! 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? Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Visualizing merge conflicts after the fact (using kdiff3)
Michael J Gruber 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Visualizing merge conflicts after the fact (using kdiff3)
Hi Micha, On 2015-06-18 14:26, Michael J Gruber wrote: > 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. Learnt something! Thanks, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Visualizing merge conflicts after the fact (using kdiff3)
Johannes Schindelin venit, vidit, dixit 16.06.2015 11:43: > 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 " 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 > ``` 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). > 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. > > Hopefully this gives you good ideas how to proceed. > > Ciao, > Johannes > Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Visualizing merge conflicts after the fact (using kdiff3)
On 6/16/2015 2:43 AM, Johannes Schindelin wrote: > 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 " 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 > . Thanks for the reply, Johannes. That basically the procedure that I did on just the one I stumbled across. But what I really want is just a way to review how each conflicts was resolved w/out having to re-resolve each one myself. gitk (obviously) makes it trivial to view changes in normal commits, but given that git provides such a straightforward conflict resolution model I'm surprised that there isn't a corresponding straightforward way of viewing those resolved conflicts in context. Thanks - Eric -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Visualizing merge conflicts after the fact (using kdiff3)
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 " 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? Thanks - Eric (raible at gmail ) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
