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

[RFC] Git rerere and non-conflicting changes during conflict resolution

From
Raman Gupta <rocketraman@gmail.com>
Date
Jul 25, 2017, 15:09 UTC
Message-ID
<17c46229-3b64-34f1-30fa-d40b77e1c054@gmail.com>

I had an interesting situation today: resolving a merge conflict required modification in other files that were not themselves conflicting.

I just realized that rerere does not remember any changes to these additional files -- only changes to the conflicting files. This makes the end result of rerere obviously incorrect in this situation.

So my questions are:
1) Is this a known limitation or is there a reason rerere works in
this manner?

1b) If it is a limitation/bug, what would be needed to fix it? With some guidance, I might be able to submit a patch...

2) In the meantime, is there a way I can identify these cases, without
which I cannot really trust rerere is doing the right thing?

Regards, Raman

Next: Jeff King
Message 1 of 10 in “[RFC] Git rerere and non-conflicting changes during conflict resolution”
  1. Raman GuptaJul 25, 2017
  2. Jeff KingJul 25, 2017
  3. Raman GuptaJul 25, 2017
  4. Jeff KingJul 25, 2017
  5. Junio C HamanoJul 25, 2017
  6. Junio C HamanoJul 25, 2017
  7. Jeff KingJul 25, 2017
  8. Junio C HamanoJul 26, 2017
  9. Junio C HamanoJul 27, 2017
  10. Junio C HamanoJul 26, 2017

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.