This is an archive of the discontinued Mercurial Phabricator instance.

merge: store commitinfo if mergetool resolved a dc or cd conflict

Authored by pulkit on Sep 5 2020, 3:10 AM.



delete-changed or changed-delete conflicts can be resolved by mergetool, either
if some tool is passed and using or by user choose something on prompt.

If the user decides to keep the changed side, on commit we just reuse the parent
filenode. This is mostly fine unless we are in a distributed environment and
people are doing criss-cross merges.

Since, we don't have recursive merges or any other way of describing the end
result of the merge was an explicit choice and it should be differentiated from
it's ancestors, merge algo during criss-cross merges fails to take in account
the explicit choice made by user and end up with a what-can-be-said-wrong-merge.

The solution which we are trying to fix this is by creating a filenode on commit
instead of reusing the parent filenode. This helps differentiate between
pre-merged filenode and post-merge filenode and kind of tells about the choice
user made.

To implement creating new filenode functionality, we store info about these
files in mergestate so that we can read them on commit and force create a new

Diff Detail

rHG Mercurial
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

pulkit created this revision.Sep 5 2020, 3:10 AM
pulkit updated this revision to Diff 22587.Sep 9 2020, 9:44 AM
marmoute requested changes to this revision.Sep 11 2020, 5:12 AM
marmoute added a subscriber: marmoute.
marmoute added inline comments.

We should get something more descriptive here. like:

Instead of:

merge code:  "sudo make a new file node"
commit code: "okay, I guess"


merge code:  "This file might have been deleted by the merge"
commit code: "ho ho ho, I'll use a new filenode to convey that !"
This revision now requires changes to proceed.Sep 11 2020, 5:12 AM
marmoute added inline comments.Sep 11 2020, 5:17 AM

We should introduce the hg debugmergstate in a previous changeset so that we know what change this one introduce. Should we not ?

This revision was not accepted when it landed; it landed in state Needs Review.
This revision was automatically updated to reflect the committed changes.