Page MenuHomePhabricator

mergestate: clear merge state if there are no unresolved conflicts
AbandonedPublic

Authored by martinvonz on Aug 18 2020, 6:37 PM.

Details

Reviewers
None
Group Reviewers
hg-reviewers
Summary

After doing e.g. hg update -m and all files get automatically
merged, we currently leave the merge state in place. That means that
the previously checked-out commit node gets displayed as % in the
log output. It also means that the user can re-resolve the files using
hg resolve, possibly using a different merge tool. I can see some
minor value in that, although I've never used it myself. However,
commands that commit the changes right away (e.g. rebase, histedit,
graft, backout, evolve) don't let the user re-resolve merged files
without redoing the whole operation. I don't think we've had requests
for that, either, so I don't think there's much reason to think that
it is useful for operations that don't commit. This patch therefore
makes us clear the mergestate if there are no unresolved conflicts.

This has a large impact on the test-merge-changedelete.t test
because that heavily exercised the re-resolve functionality.

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

martinvonz created this revision.Aug 18 2020, 6:37 PM

The ability to re-run the merge seems quite important and I fear the BC implication. What are the issue with keeping the file around? The one issue I see listed is the use of % in hg log could we tackle that directly instead?

The ability to re-run the merge seems quite important and I fear the BC implication.

I've never had to use that, but I can see how someone might want to run hg co .^ -m -t :local; hg resolve -t <specific file>, so I'm also slightly concerned about it.

What are the issue with keeping the file around? The one issue I see listed is the use of % in hg log

I also mentioned it showing up in hg resolve -l. It also shows up in hg status -v (as a "# No unresolved merge conflicts." line being present).

could we tackle that directly instead?

Do you mean that we could make hg log -G not show % if all conflicts are resolved? Maybe we'd do the same for hg status -v in that case? But probably leave hg resolve -l alone?

Do you mean that we could make hg log -G not show % if all conflicts are resolved? Maybe we'd do the same for hg status -v in that case? But probably leave hg resolve -l alone?

Yeah, something like that. That is is not great, but still seems better than blindly dropping the mergestate.

Maybe we could have hg continue play a role here ? leaving hg resolve and hg status -v as they are now and pointing at hg continue to drop the merge state. (maybe still fix the log output in all case?)

martinvonz abandoned this revision.Thu, Sep 10, 4:13 PM

Abandoning this in favor of D9007.