Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 13:58:14 +0530] rev 45585
commit: force create a new filenode if it was set in mergestate by merge
For reasons mentioned in previous commits, we will like to forcefully create a
new filenode sometimes.
Combination of this patch and previous one, we fixed a case in
`test-merge-combination.t`.
This does not yet results in conflict where it should, I need to investigate
more about what's happening as it should be a change-delete conflict now.
Differential Revision: https://phab.mercurial-scm.org/D8989
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 13:44:06 +0530] rev 45584
merge: store commitinfo if these is a dc or cd conflict
delete-changed or changed-delete conflicts can either be resolved by mergetool,
if some tool is passed and using or by user choose something on prompt or user
doing some `hg revert` after choosing the file to remain conflicted.
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
filenode.
Differential Revision: https://phab.mercurial-scm.org/D8988
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 25 Sep 2020 13:58:05 +0530] rev 45583
mergestate: update _stateextras instead of reassinging
`merge.applyupdates()` can store extras for a file and _stateextras may not be
empty always. Hence reassigning loses the old values.
We can directly update like this because we switched to using
`collections.defaultdict` for `_stateextras` sometime ago.
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 14:11:45 +0530] rev 45582
tests: add some debugmergestate calls in `test-merge-criss-cross.t`
This will help notice the change in upcoming patches much better.
Differential Revision: https://phab.mercurial-scm.org/D9028
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Sep 2020 13:54:46 +0530] rev 45581
tests: add few debugrevlogindex and a log call to see changes in next test
In upcoming patches, we will create a new filenode in couple of cases. Let's add
some debugrevlogindex and a log call so that we can observe those changes
better.
Differential Revision: https://phab.mercurial-scm.org/D8987
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 14:40:12 +0530] rev 45580
merge: disable `m2-vs-ma` optimization if new filenode config is true
The `m2-vs-ma` optimization filters out the file which have not changed between
second parent and the ancestor of the merge. This results in the m1-vs-m2 diff
not processing those files. These files will be required when we are creating
new filenode for salvaged cases as we need to track them to store in mergestate
that file can be salvaged.
Differential Revision: https://phab.mercurial-scm.org/D9027
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 14:31:23 +0530] rev 45579
configitems: add a new config option to control new filenode functionality
This series is adding functionality where we can force create a new filenode for
some files on a merge-commit. This is meant to represent an explicit choice made
by user and hence distingusing the file in the merged commit with the file in
parent by creating a new filenode instead of using the parent one.
This introduces a experimental config option under which this functionality
will be hidden.
A new testcase is added in tests/test-merge-criss-cross.t to test the new
functionality while making the option does not break other scenarios.
Differential Revision: https://phab.mercurial-scm.org/D9026
Connor Sheehan <sheehan@mozilla.com> [Wed, 23 Sep 2020 14:20:49 -0400] rev 45578
git: add test showing `hg commit -i` working on a git repo
Shows `hg commit -i` working on a git repo via the `git`
extension. Adds working directory changes to files `alpha` and
`beta`, then selects only `alpha` changes and commits them.
As of now this would fail for a filename that
includes uppercase characters due to the lack of case folding
support in the extension.
Differential Revision: https://phab.mercurial-scm.org/D9081
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 11:53:44 -0700] rev 45577
merge: replace calls to hg.updaterepo() by merge.update()
The former no longer buys us anything.
Differential Revision: https://phab.mercurial-scm.org/D9067
Martin von Zweigbergk <martinvonz@google.com> [Mon, 21 Sep 2020 09:57:29 -0700] rev 45576
merge: add a higher-level update() for the common `hg update` use case
This is different from the `update()` function that I just made
private. The new function is specifically for the normal `hg update`
use case. It doesn't do a merge and it doesn't do a clean (forced)
update.
Differential Revision: https://phab.mercurial-scm.org/D9066