Elijah Newren <newren@xxxxxxxxx> writes: > * Can we rely on the extension being written and populated? (does it > get populated by all relevant codepaths in git?) The only place record_resolve_undo() gets called is in the deep guts of in-core index manipulation where a conflicted entry is removed (either because the resolution decided was to remove the path, or the resolution is about to add the final contents for the path at the stage #0), so yes, as long as you are manipulating the in-core index using our API, you should be recording the action. Otherwise we have a bug, as "--unresolve" has to work correctly all the time. > * Even if all codepaths in git will populate it, might the lack of > this extension (or its lack of entries) imply that the user used some > other tool (jgit, something in libgit2, etc.) rather than that there > were no conflicts? It is possible that third-party tools are buggy and corrupt the on-disk index that way. > * Can we rely on this for all types of conflicts? For all merge > backends? Are there conflict types that don't result in a higher > stage entry being recorded in the index? Interesting thought. I am not confident that the recent "directory rename" stuff does not break the undo information along that line. But at least, the idea is that resolve-undo should be able to reproduce the state immediately after any mergy operation stopped due to conflicts by resurrecting the higher stage entries. But I do not think "we had a conflict" is so black and white to begin with. If you have a rerere record and rerere.autoupdate enabled (not recommended), does it mean you didn't have a conflict when rerere kicks in and you did not have to touch anything to resolve it this time, or was there a conflict but it was auto-reoslved? I think the "unresolve" mechanism should still record the higher stage entries that gets created first before rerere.autoupdate removes them, which matches the latter interpretation that I happen to agree with. For that matter, if both sides have made changes to the same file nearby, it is more coherent if we declare that there is a conflict whether the changes "overlap", as the definition of overlapping is fuzzy and depending on the inter-hunk context used during the mergy operation, what humans would consider "close but not overlapping" gets flagged as a "close enough to warrant manual inspection" conflict (and you can think of rerere as a way to automate that 'manual inspection' step reusing the prior resolution). So I'd vote for "No conflicts remain, but you haven't committed", which would be the most sensible way to phrase the situation.
