Re: git status when merging non-conflicted 3-way merge says "All conflicts fixed"

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> 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.