Strip have dedicated work around to solve the same problem, strip is even a
fraction faster without that thanks to simpler update process of the branchcache.
Many tests didn't change back from subdirectories at the end of the tests ...
and they don't have to. The missing 'cd ..' could always be added when another
test case is added to the test file.
This change do that tests (99.5%) consistently end up in $TESTDIR where they
started, thus making it simpler to extend them or move them around.
I named it --check because it felt like qpush & co were checking *more*
things to ensure local changes could not be lost. But it has been
pointed on the mailing list that --check is already used by update
command with a meaning almost opposite to this one. An alternative
was --keep but qfold and qdelete already have such an option to preserve
patch files and qfold may be a candidate for --check.
- qpush/qpop/qgoto --check becomes --keep-changes.
- mq.check becomes mq.keepchanges.
- The short option -c is dropped as -k may conflict with existing
--keep. The availabilitity of mq.keepchanges should not make this too
painful.
- Fix minor reST mistake in option description.
When:
[mq]
check = True
is set, qpush, qpop and qgoto behave as if -c/--check were passed. If
incompatible options like -f/--force or --exact are set, this setting is
ignored.
This setting enables what many users expect mq default behaviour to be.
qpush help says the following about --force:
1- When -f/--force is applied, all local changes in patched files will
be lost.
2- Apply on top of local changes
In practice, qpush --force will attempt to apply the patch on top of
local changes, and on success will merge them in the pushed patch. On
failure, patched files will contain a mix of local changes (where the
patch could not apply) and a mix of patch changes (were it applied). So,
local changes are less lost than entangled with a mass of other changes.
This patch makes qpush --force backup all locally modified files touched
by the next patch being applied. When multiple patches are being pushed,
this logic is repeated for each patch. Note that modified but
successfully patched files are preserved as well.
The internal list representation of guards was leaking into the
output. The guards were always printed using repr(guard) and that
style was kept.
When "hg qguard -l" prints several guards for a patch, it does so by
joining the names with " " and that style was used for the error
messages too.
We can't assume that all pushable patches early in the series have already been
applied. If a hg qselect is done while you already have patches applied, some
patches with guards may now be pushable, even though they come earlier in the
series.
So instead of checking only applied patches, explicitly check where we are in
the series against the position of the patch we want to qpush to.