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

Re: [PATCH 9/9] rerere forget path: forget recorded resolution

From
Johannes Sixt <j6t@kdbg.org>
Date
Jan 11, 2010, 19:22 UTC
Message-ID
<201001112022.31257.j6t@kdbg.org>
In-Reply-To
<7v4omte72j.fsf@alter.siamese.dyndns.org>
On Montag, 11. Januar 2010, Junio C Hamano wrote:
> I ended up doing this myself.  As we are dropping the postimage and adding
> a new MERGE_RR entry, I also think that it is safer to update the preimage
> with the conflict we got for this round, so I added that as well.

Thank you, it appears to work as expected. It is actually very important to update the preimage as well, otherwise, the new postimage can contain unrelated additional changes.

Show 7 quoted lines
> However, I think there is a room for improvement in preimage handling.
>
> Currently, the rerere database is indexed with the conflict hash and for
> each conflict hash you can record a single preimage-postimage pair to
> replay.  But you can have conflicts with the same conflict hash, but with
> slightly different contexts outside the conflicted region, and the right
> resolution can be different depending on the outside context.

I did encounter a case where the same resolution would apply to all conflicts that have the same conflict hash, so it's not quite what you talk about. But not all conflicts were automatically resolved. I haven't yet analyzed what happened - it could just be that the xdl_merge call fails due to the differences in the text immediately outside the conflict markers.

Show 9 quoted lines
> In the traditional implementation, I punted this issue by noticing
> conflicts in the three-way merge between pre, post and this images.  If
> preimage is too different from the conflicted contents we got during this
> merge, then the previous resolution should not apply.
>
> But I think the right solution would be to have more than one preimage and
> postimage pairs (preimage.0 vs postimage.0,... etc.) and try to use each
> of them in handle_path() until it finds one that can be used to cleanly
> merge with the conflict we got in thisimage during this round.

The situation happens rarely, so I don't know if we should care. OTOH, *when* the situation arises, and a recorded resolution is applied incorrectly, it may be quite annoying. Dunno.

-- Hannes
Previous: Junio C HamanoNext: Junio C Hamano
Message 19 of 21 in “Undoing conflict resolution”
  1. 0/9 Undoing conflict resolutionJunio C Hamano, Dec 29, 2009
  2. 1/9 builtin-merge.c: use standard active_cache macrosJunio C Hamano, Dec 29, 2009
  3. 2/9 resolve-undo: record resolved conflicts in a new index extension sectionJunio C Hamano, Dec 29, 2009
  4. 3/9 resolve-undo: basic testsJunio C Hamano, Dec 29, 2009
  5. 4/9 resolve-undo: allow plumbing to clear the informationJunio C Hamano, Dec 29, 2009
  6. 5/9 resolve-undo: "checkout -m path" uses resolve-undo informationJunio C Hamano, Dec 29, 2009
  7. 6/9 resolve-undo: teach "update-index --unresolve" to use resolve-undo infoJunio C Hamano, Dec 29, 2009
  8. 7/9 rerere: remove silly 1024-byte line limitJunio C Hamano, Dec 29, 2009
  9. 8/9 rerere: refactor rerere logic to make it independent from I/OJunio C Hamano, Dec 29, 2009
  10. 9/9 rerere forget path: forget recorded resolutionJunio C Hamano, Dec 29, 2009
  11. Johannes SixtJan 5, 2010
  12. Junio C HamanoJan 6, 2010
  13. Johannes SixtJan 6, 2010
  14. Junio C HamanoJan 6, 2010
  15. Junio C HamanoJan 6, 2010
  16. Johannes SixtJan 8, 2010
  17. Junio C HamanoJan 8, 2010
  18. Junio C HamanoJan 11, 2010
  19. Johannes SixtJan 11, 2010
  20. Junio C HamanoJan 11, 2010
  21. Johannes SixtJan 11, 2010

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.