On 5 March 2011 06:20, Adam Monsen <haircut@xxxxxxxxx> 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. > > Â Â~ * ~ > > Here's some details in case anyone wants to (a) point out where I messed > up or (b) help me avoid this kind of blunder in the future. > > 1. The repo is git://mifos.git.sourceforge.net/gitroot/mifos/head > (mirror: https://github.com/mifos/head ). Branch master. > > 2. My commit 2a1ed0436 introduced a fix that includes the text > "native2ascii". Shows up in "git log -p -1 2a1ed0436" and "git show > 2a1ed0436". Life is good. > > 3. It appears that the merge commit 0f8132386 tossed my "native2ascii" > fix. The only way I could figure out to actually visualize this is "git > diff 58320586..0f813238". > > This took a while to figure out. Am I missing something obvious? Seems like a bunch of people (myself included) have been tripped up by this behaviour in the past few months. Did something change to start this, or has it always been there? -Jonathan -- 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