git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date
Mar 5, 2011, 14:29 UTC
Message-ID
<alpine.DEB.2.00.1103050844130.26585@debian>
In-Reply-To
<4D71D63E.3030907@gmail.com>
On Fri, 4 Mar 2011, Adam Monsen wrote:
Show 14 quoted lines
> 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
Previous: Adam Monsen
Message 26 of 26 in “frustrated forensics: hard to find diff that undid a fix”
  1. Adam MonsenMar 5, 2011
  2. Jonathan del StrotherMar 5, 2011
  3. Jakub NarebskiMar 5, 2011
  4. Jonathan NiederMar 5, 2011
  5. Jeff KingMar 5, 2011
  6. Adam MonsenMar 5, 2011
  7. 0/2 improve combined diff documentationAdam Monsen, Mar 5, 2011
  8. 1/2 documentation fix: git log -p does not imply -c.Adam Monsen, Mar 5, 2011
  9. Junio C HamanoMar 7, 2011
  10. Jeff KingMar 7, 2011
  11. Junio C HamanoMar 7, 2011
  12. Jeff KingMar 7, 2011
  13. Documentation fix: git log -p does not imply -c.Adam Monsen, Mar 7, 2011
  14. Junio C HamanoMar 8, 2011
  15. Documentation fix: git log -p does not imply -c.Adam Monsen, Mar 8, 2011
  16. Junio C HamanoMar 8, 2011
  17. Adam MonsenMar 8, 2011
  18. Junio C HamanoMar 9, 2011
  19. Adam MonsenMar 9, 2011
  20. SubmittingPatches: clean up commit message tipsAdam Monsen, Mar 9, 2011
  21. Junio C HamanoMar 9, 2011
  22. diff format documentation: clarify --cc and -cAdam Monsen, Mar 8, 2011
  23. diff format documentation: clarify --cc and -cAdam Monsen, Mar 8, 2011
  24. Jeff KingMar 8, 2011
  25. 2/2 English grammar fixes for combined diff doc.Adam Monsen, Mar 5, 2011
  26. Martin von ZweigbergkMar 5, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.