Summary:
Renaming it to `generateworkingcopystates`. This is a valid module name.
The goal is to convert this script to a module. While we are converting
tests it needs to be accessible in both script form and module.
Reviewed By: singhsrb
Differential Revision: D17611370
fbshipit-source-id: 0b2d0de71f0da7cd6efd7874c505d9aa77f7b296
Summary:
When the rebase destination has renamed a file, and copytrace failed to figure
out anything useful, make it possible to manually input the rename destination.
I'm using it to resolve conflicts caused by landing the bindings rename.
Reviewed By: xavierd
Differential Revision: D17367857
fbshipit-source-id: 55d9ed3a9641e40cc43518e9662fd803cbc00620
Summary:
When you get an error, let's print the number of conflicts in each file. This will give the user some sense of how much work they have to do.
The code change is entirely in `filemerge.py`, and `tests/test-merge-conflict-count.t` adds a new test.
Reviewed By: quark-zju
Differential Revision: D9815243
fbshipit-source-id: 1b73a1db293902ac7242997a7d6ae09478344068
Summary:
Enable it by default so all tests run with it.
The test changes are mostly caused by repo requirement changes.
Reviewed By: DurhamG
Differential Revision: D8880991
fbshipit-source-id: f96cecfd85b8088098c3b55d06ab0374ee93437b
Summary:
The test change actually indicates treestate is more correct. Therefore
a comment about the old behavior "doesn't make sense" is removed:
> *_missing_missing_missing-tracked is reported as removed ('R'), which
> doesn't make sense since the file did not exist in the parent, but on the
> other hand, merged-in additions are reported as modifications, which is
> almost as strange.
Reviewed By: DurhamG
Differential Revision: D8869837
fbshipit-source-id: 1102abc9d41f4ec657ce7c8569ef8159e88b2578
Summary:
The helper could be used in individual tests to enable chg if chg exists.
This allows us to have more precise control on what tests to use chg instead
of using a global flag in run-tests.py.
This makes certain tests containing many hg commands much faster. For example,
`test-revset.t` took 99 seconds before:
% ./run-tests.py test-revset.t --time
.
# Ran 1 tests, 0 skipped, 0 failed.
# Producing time report
start end cuser csys real Test
0.000 99.990 86.410 12.000 99.990 test-revset.t
And 10 seconds after:
% ./run-tests.py test-revset.t --time
.
# Ran 1 tests, 0 skipped, 0 failed.
# Producing time report
start end cuser csys real Test
0.000 10.080 0.380 0.130 10.080 test-revset.t
Also enable it for some other tests. Note the whitelist is not complete. We
probably want to whitelist more tests in the future.
The feature could be opted out by deleting `contrib/chg/chg`.
Reviewed By: phillco
Differential Revision: D6767036
fbshipit-source-id: 8220cf408aa198d5d8e2ca5127ca60e2070d3444
The way default marker template was defined before this patch,
the spacing before dash in conflict markes was dependent on
whether changeset is a tip one or not. This is a relevant part
of template:
'{ifeq(tags, "tip", "", "{tags} "}'
If revision is a tip revision with no other tags, this would
resolve to an empty string, but for revisions which are not tip
and don't have any other tags, this would resolve to a single
space string. In the end this causes weirdnesses like the ones
you can see in the affected tests.
This is a not a big deal, but double spacing may be visually
less pleasant.
Please note that test changes where commit hashes change are
the result of marking files as resolved without removing markers.
Now that we store and display merge labels in user prompts (not just
conflict markets), we should rely on labels to clarify the two sides of a
merge operation (hg merge, hg update, hg rebase etc).
"remote" is not a great name here, as it conflates "remote" as in "remote
server" with "remote" as in "the side of the merge that's further away". In
cases where you're merging the "wrong way" around, remote can even be the
"local" commit that you're merging with something pulled from the remote
server.
In an upcoming patch we're going to change the behavior of some merges with
merge.checkunknown=warn or ignore -- ensure that the behavior of the deprecated
'merge --force' remains the same.
It makes far more sense to leave these conflicts unresolved and kick back to
the user than to just assume that the local version be chosen. There are almost
certainly buggy scripts and applications using Mercurial in the wild that do
merges or rebases non-interactively, and then assume that if the operation
succeeded there's nothing the user needs to pay attention to.
(This wasn't possible earlier because there was no way to re-resolve
change/delete conflicts -- but now it is.)
This came up before, but the tests in check-code.py don't find -U (only -u)
and they don't work when the diff is inside a shell function. This fixes
the offending tests and beefs up check-code.py.
We have finally laid all the groundwork to make this happen.
The only change/delete conflicts that haven't been moved are .hgsubstate
conflicts. Those are trickier to deal with and well outside the scope of this
series.
We add comprehensive testing not just for the initial selections but also for
re-resolves and all possible dirstate transitions caused by merge tools. That
testing managed to shake out several bugs in the way we were handling dirstate
transitions.
The other test changes are because we now treat change/delete conflicts as
proper merges, and increment the 'merged' counter rather than the 'updated'
counter. I believe this is the right approach here.
For third-party extensions, if they're interacting with filemerge code they
might have to deal with an absentfilectx rather than a regular filectx.
Still to come:
- add a 'leave unresolved' option to merges
- change the default for non-interactive change/delete conflicts to be 'leave
unresolved'
- add debug output to go alongside debug outputs for binary and symlink file
merges
We're going to soon compare the output of all the non-orig files before and
after a resolve, and this makes that more convenient. The .orig files are
obviously going to differ between the two.
We perform all that we can non-interactively before prompting the user for input
via their merge tool. This allows for a maximally consistent state when the user
is first prompted.
The test output changes indicate the actual behavior change happening.
The current output for a failed merge with conflict markers looks something like:
merging foo
warning: conflicts during merge.
merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
merging bar
warning: conflicts during merge.
merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
We're going to change the way merges are done to perform all premerges before
all merges, so that the output above would look like:
merging foo
merging bar
warning: conflicts during merge.
merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
warning: conflicts during merge.
merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
The 'warning: conflicts during merge' line has no context, so is pretty
confusing.
This patch will change the future output to:
merging foo
merging bar
warning: conflicts while merging foo! (edit, then use 'hg resolve --mark')
warning: conflicts while merging bar! (edit, then use 'hg resolve --mark')
The hint on how to resolve the conflicts makes this a bit unwieldy, but solving
that is tricky because we already hint that people run 'hg resolve' to retry
unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker
based resolution.
With generate-working-copy-states.py generalized to support
arbitrarily many changesets, we can use it for generating test cases
for merge: use one changeset each for base, remote and local. With the
various working copy states, this is a total of 104 cases.
The first candidate for additional testing is 'hg merge --force'. Even
though the force option is deprecated, it is convenient for testing
because it can be tested without first needing to revert any
changes. Except for the lack of checking for uncommitted changes, it
differs in only a few cases from unforced merge.
The new tests cover all the cases in the existing test-merge-force.t,
except for the unforced merge case, which is covered in several other
files anyway, so nothing remains of the file after this patch.
Makes the 'nothing to merge' abort messages in commands.py consistent with
those in merge.py. Also makes commands.merge() and merge.update() use hints.
The tests show the changes.
