So we can easily compare it with the corresponding getopt() result.
There's a minor behavior change. Before, "hg --cwd ''" failed with ENOENT.
But with this patch, an empty cwd is silently ignored. "hg -R ''" has always
worked as such, so -R has no BC.
This allows us to parse the original args later by full-blown getopt() in
order to verify the result of the faulty early parsing. Still we need the
'strip=True' behavior for shell aliases.
Note that this series is RFC because it seems to change too much to be
included in stable release.
Perhaps we'll need to restrict the parsing rules of --debugger and --profile,
where this patch will help us know why the --debugger option doesn't work.
I have another series to extend this feature to --config/--cwd/-R, but even
with that, shell aliases can be used to get around the restriction.
This is a minimal copy of localrepo.commit(). As the current amend() function
heavily depends on the wctx API, it wasn't easy to port it to use a separate
status tuple. So for now, wctx._status is updated in-place.
This demonstrates that missing/untracked files are handled incorrectly. The
correct outputs are suppressed by (false !), and wrong outputs are added with
(true !) instead.
The setup code is copied from test-status-rev.t.
When origbackuppath is set, when looking to see if a file we are backing up
conflicts with a directory in the origbackuppath, we incorrectly match on
symlinks to directories. This means we try to call vfs.rmtree on the
symlink, which fails.
Differential Revision: https://phab.mercurial-scm.org/D1311
If origbackups are in use, a symlink to a valid directory is backed up, and an
update is made that attempts to backup a file or link over that symlink, we
abort with a bad error message instead of successfully updating.
Differential Revision: https://phab.mercurial-scm.org/D1310
We change subrepos.allowed from a list of allowed subrepo types to
a combination of a master switch and per-type boolean flag.
If the master switch is set, subrepos can be disabled wholesale.
If subrepos are globally enabled, then per-type options are
consulted. Mercurial repos are enabled by default. Everything else
is disabled by default.
These config items control share behavior that is implemented in core.
Since the functionality is implemented in core, extensions may
leverage it.
Mozilla has one such extension. And, it needs to access share.pool.
Before this patch, a devel warning regarding accessing an unregistered
config option would be issued unless the share extension were loaded.
Moving the registration of the config options to core fixes this.
We have a security issue with git subrepos. I'm not sure if svn subrepo is
vulnerable, but it seems not 100% safe to allow writing arbitrary data into
a metadata directory. So for now, only hg subrepo is enabled by default.
Maybe we should improve the help to describe why git/svn subrepos are
disabled.
This allows us to minimize the behavior change introduced by the next patch.
I have no idea which config style is preferred in UX POV, but I decided to
get things done.
a) list: 'allowed = hg, git, svn'
b) sub option: 'allowed.hg = True' or 'allowed:hg = True'
c) per-type action: 'hg = allow', 'git = abort'
This is an alternative workaround for the issue5730.
Perhaps this is the simplest way of disabling subrepo operations. It does
nothing clever, but just aborts if Mercurial starts accessing to a subrepo.
I think Greg's patch is more useful since it allows us to at least check
out the parent repository. However, that would be confusing if the default
is flipped to checkout=False and subrepos are silently ignored.
I don't like the config name 'allowed', but I couldn't get any better name.
Previously, if there were unresolved files and the CWD drive was different from
the repo drive, `hg status -v` would page the normal status, followed by the
exception header. A stacktrace was waiting when the pager exited. The
underlying cause was the same as 12441ef4442f.
Unfortunately, I don't see any reasonable way to write a test this [1].
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/107401.html
This is a followup to 12441ef4442f. Since there's no way to ensure that more
drive letters than C: exist, this seems like the only way to test it. This is
enough to catch the 12441ef4442f scenario, as well as CWD outside of the repo
when the path isn't prefixed with path/to/repo.
It wasn't easy to extend the pathauditor to check symlink traversal across
subrepos because pathauditor._checkfs() rejects a directory having ".hg"
directory. That's why I added the explicit islink() check.
No idea if this patch is necessary after we've fixed the issue5730 by
splitting submerge() into planning and execution phases.
os.path.relpath() exploded if the 'root' and 'cwd' directories had different
drive letters. I noticed this in TortoiseHg when typing a fileset into the
filter, and it kept complaining until the closing '()' was typed. This was
reproducible on the command line with:
$ cd /d
$ hg -R /c/Users/Matt/Projects/hg files 'set:e'
Traceback (most recent call last):
...
File "mercurial\pathutil.pyc", line 182, in canonpath
File "ntpath.pyc", line 529, in relpath
ValueError: path is on drive c:, start on drive d:
When cwd is removed and `hg` is executed, some shells may run `getcwd`
before forking and executing, some may not do it, some may print a
different error message.
The test should be shell-independent so let's just avoid checking the error
message.
Differential Revision: https://phab.mercurial-scm.org/D1282
The original condition was a bit harsh for extension authors since third-party
extensions need to preserve compatibility with older Mercurial versions, where
no defaults would be loaded from the configtable. So let's silence the warning
if the given default value matches, which should be harmless.
After a refactoring, _toolstr stopped having default="" as one of it's args,
therefore when called without a default it returns None and not "". This causes
concatenation to fail.
We've found a severe perf regression in `hg update` caused by the path conflict
checking code. The next patch will disable this by default.
Differential Revision: https://phab.mercurial-scm.org/D1222
When a dirstate backup is restored, it is possible that no actual changes to
the dirstate have been made. In this case, the backup is still a hardlink
to the original dirstate.
Unfortunately, `os.rename` silently fails (nothing happens, and no error
occurs) when `src` and `dst` are hardlinks to the same file. As a result,
the backup is left lying around. Over time, these files accumulate.
When restoring dirstate backups, check if the backup and the dirstate are
the same file, and if so, just delete the backup.
Differential Revision: https://phab.mercurial-scm.org/D1201
I'm not sure why these weren't working on Windows. The failures were generally
in the style of:
- remote: phase-move: cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b: 1 -> 0
+ remote: "phase-move: $HG_NODE: $HG_OLDPHASE -> $HG_PHASE"
and
- abort: pretxnclose-bookmark.force-forward hook exited with status 1
- [255]
+ abort: pretxnclose-bookmark.force-public hook exited with status 255
+ [255]
These failures originated in 5625d0ddc285::6e3e88681b23.
Previously, the second last test (context.arbitraryfilectx(..)) returned True on
Windows. I changed the repo setup sequence to import a patch, so that way the
repo would have a proper symlink. That made the last test fail, since it is
comparing files in wdir(), one of which is not the expected symlink.
Apparently the (feature !) line matching doesn't work well with (no-eol), so I
had to conditionalize the test instead of the output.
