Re: frustrated forensics: hard to find diff that undid a fix

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

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