On 05/24, Junio C Hamano wrote: > Thomas Gummerer <t.gumme...@gmail.com> writes: > > > To fix this, remove the rerere ID from the MERGE_RR file in case we > > can't handle it, and remove the folder for the ID. Removing it > > unconditionally is fine here, because if the user would have resolved > > the conflict and ran rerere, the entry would no longer be in the > > MERGE_RR file, so we wouldn't have this problem in the first place, > > I do not think removing the directory and losing _other_ conflicts > and their resolutions, if they exist, is fine in the modern world > order post rerere-multi update in 2016. Well, it is just as safe as > "rm -rf .git/rr-cache/" in the sense that it won't make Git start > segfaulting, but it is not fine as it is discarding information of > conflicts that has nothing to do with the current one that is > problematic.
Sorry I botched the description here, and failed to describe what the code is actually doing. We're actually only removing the variant in the MERGE_RR file, whose path we are now no longer able to handle. And I think that's fine to do, because if it is still in the MERGE_RR file the conflict hasn't been resolved yet, afaiu. Will update the commit message.
