Re: [RFC/PATCH 4/7] rerere: fix crash when conflict goes unresolved

2018-05-24 Thread Junio C Hamano
Thomas Gummerer writes: > 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. Oh, that's absolutely fine, then.

Re: [RFC/PATCH 4/7] rerere: fix crash when conflict goes unresolved

2018-05-24 Thread Thomas Gummerer
On 05/24, Junio C Hamano wrote: > Thomas Gummerer 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

Re: [RFC/PATCH 4/7] rerere: fix crash when conflict goes unresolved

2018-05-24 Thread Junio C Hamano
Thomas Gummerer 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

[RFC/PATCH 4/7] rerere: fix crash when conflict goes unresolved

2018-05-20 Thread Thomas Gummerer
Currently when a user doesn't resolve a conflict in a file, but commits the file with the conflict markers, and later the file ends up in a state in which rerere can't handle it, subsequent rerere operations that are interested in that path, such as 'rerere clear' or 'rerere forget ' will fail, or