David Aguilar <davvid@xxxxxxxxx> writes:
> We can have a "default" unmerged files provider that does the
> `test -s .../MERGE_RR` check since that would probably deal with
> this ugly edge case.
>
> We can then teach this default thing to be smarter and skip text files
> with no merge markers. Junio, is this what you were thinking?
> This sounds like a nice way to me.
I am not sure what I were thinking ;-) so let me think aloud.
In any case, once the user says (either via directly using "git add"
or using the command via the mergetool) the path is resolved,
mergetool would no longer want to touch it, until the user says
"oops, the resolution was a mistake; pleae make it unresolved again"
with something like "git checkout -m". So in this message, I'll
think only about the case where the index is still unmerged.
The working tree files may be in one of these states:
1. It may still be the same as the conflicted state after the
three-way merge proper gave the user, perhaps with conflict
markers in the text.
2. rerere or some other mechanism (this includes manual editing or
previous run of "mergetool") may have resolved the conflict
fully.
3. Or such a mechanism may have only half-resolved the conflict.
As far as I can see, the mergetool machinery, once it decides to
feed a path to the mergetool backend, ignores what is in the working
tree file, and uses the stage #2 (i.e. the state before merge
happened) as LOCAL (and stage #1 as BASE, stage #3 as REMOTE) to
redo the entire three-way merge from scratch.
So "ask rerere what it hasn't resolved" would only safely work for
the first kind, where the state in the working tree file is known to
be expendable.
If it can somehow determine paths that have been fully resolved, it
can (and should) skip redoing the three-way merge. And that is
probably what the "if test -s MERGE_RR; then rerere remaining; fi"
logic under discussion is about.
But that will still risk losing any half-resolution done by external
means (the third category), including manual editing. Is that a
good thing?
Perhaps there were two conflicting hunks and one of them the user
has resolved manually, and then the other one was a bit more complex
than the user wanted to resolve in the editor and that is why the
user is now running "mergetool" to resolve it in a GUI. "rerere"
will say "I didn't touch that path", and "mergetool" will happily
ignore user's manual resolution of one hunk in the working tree, and
the user ends up redoing the whole three-way merge for the path, no?
Even if you switch that logic from "asking rerere" to "look for
conflict markers", it wouldn't change the story. Perhaps "rerere
remaining" was a useless addition, and instead we probably should
have a way to ask "rerere" if the working tree file is different
from what the mergy operation left before "rerere" tried to work on
it? If it is unchanged, then we know nobody (either the user, any
third-party mechanism, or rerere) touched it and it is safe for a
mergetool backend to redo the three-way merge from scratch (i.e. we
know that is in the first category).
Otherwise, you are risking to stomp on the change that may have been
done between the time the mergy operation was done and "mergetool"
was started.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html