On Fri, 4 Mar 2011, Adam Monsen wrote: > I made a fix a month ago on the master branch in a shared repo. A week > later, a colleague did a merge that undid the fix. I didn't figure out > the problem until just now because I'd been assuming the fix was still > on master. I mean, if it wasn't, I should see a reverse patch using "git > log -p master", right? Wrong. Turns out the fix was undone as part of > merge conflict resolution (I think). > > Is there some way to include merge conflict resolutions in "git log -p" > or "git show"? Apparently some important information can be hidden in > the conflict resolution. Or, more likely, I just don't understand how > this bit of git works. > > I also tried bisect and pickaxe. Bisect wrongly identified the first bad > commit, and pickaxe just didn't see the change at all. I was also bitten by this at work not too long ago. I started wondering if it would make sense to introduce a new option to git log and friends that would show the differences compared to a recreated merge commit. In the simple case where there are no merge conflicts, this would show only changes that someone explicitly dropped, like in your case. If there were conflicts, I imagine it would show the same output as -c or --cc. Does this make any sense? One of the reasons that people sometimes drop the 'theirs' side while merging is that they see the files show up when running 'git status' and they think "Hmm... I didn't modify this file, let's reset it". Would it be completely nonsensical to suggest that 'git status' could learn to, during a merge, compare to a recreated merge commit instead of comparing to HEAD? Let me know what you think. I haven't really thought this through, so I wouldn't be surprised if I'm just talking nonsense. /Martin -- 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