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.
A recent refactor added a layer of abstraction to the dirstate which makes doing
things like 'foo in dirstate' now require some extra Python attribute lookups.
This is causing a 100ms slow down in hg status for mozilla-central.
The fix is to hoist the inner dict's functions onto the main class once the lazy
loading it complete, as well as store the actual functions before doing the
status loop (as is done for other such functions).
In my testing, it seems to address the performance regression, but we'll
need to see the perf run results to know for sure.
Differential Revision: https://phab.mercurial-scm.org/D1257
Before the recent refactor, we would not load the entire map until it was
accessed. As part of the refactor, that got lost and even just trying to load
the dirstate parents would load the whole map. This caused a perf regression
(issue5713) and a regression with static http serving (issue5717).
Making it lazy loaded again fixes both.
Differential Revision: https://phab.mercurial-scm.org/D1253
A future diff will move the lazy loading aspect of dirstate to the dirstatemap
class. This means it requires a slightly different strategy of clearing than
just reinstantiating the object (since just reinstantiating the object will
lazily load the on disk data again later instead of remaining permanently
empty).
So let's give it it's own clear function.
Differential Revision: https://phab.mercurial-scm.org/D1252
The same applies to '?' if --quiet is used (or any of the other states if some
of -marduic is specified), but I couldn't figure out how to express that
clearly.
This seems a bit hacky, but works well. There should be no reason that
static-http repo had to load dirstate.
Initially I tried to proxy os.stat() call through vfs so that statichttpvfs
could hook it, but there wasn't a good error value which the statichttpvfs
could return to get around the util.filestat issue.
If we're going to use the user's installed and configured hg command
(which we do since a4a6cb293e63), we should prevent devel-warn messages
from interfering with locating it.
The _unamenddirstate() function was inspired by _uncommitdirstate() function as
the logic was same but we were unable to use the latter function directly. So
previous patch introduced the _unamenddirstate() function and now this patch
unifies both the function and we have a _fixdirstate() function.
Adding function in previous patch and unifying in a later patch makes the
reasoning easier and also leaves the last patch dedicated to what it is meant to
be.
Differential Revision: https://phab.mercurial-scm.org/D971
The short options "-c" and "-C" may be confusing for a novice reading the
documentation. Let's try to be more explicit, also mentioning the equivalent
long options ("--check" and "--clean") in the comments.
If the legacy pager extension is enabled, a pager is started through repo.ui
at dispatch._runcommand(). After that, mqcommand() creates a qrepo with a
fresh repo.baseui, at which point pager information was lost and another pager
would be spawned by the modern pager interface.
This is a minimal workaround for the problem.
unamend extension adds an unamend command which undoes the effect of the amend
command. This patch moves the unamend command from that extension to uncommit
extension and this one does not completely undoes the effect of amend command as
it creates a new commit, rather than reviving the old one back.
This also adds tests for the same.
.. feature::
A new unamend command in uncommit extension which undoes the effect of the
amend command by creating a new changeset which was there before amend and
moving the changes that were amended to the working directory.
Differential Revision: https://phab.mercurial-scm.org/D821
I'd also like --color=always on the command-line to override HGPLAIN=1
et al, but that's more work, and this seems like a better fix. We've
got a fair number of programs that actually want to automate hg and
get colored output to users, so they should set HGPLAINEXCEPT=alias
(what we usually recommend), but this has been breaking them because
they then lose color.
.. feature::
The ``HGPLAINEXCEPT`` environment variable can now include ``color``
to allow automatic output colorization in otherwise automated
environments.
Differential Revision: https://phab.mercurial-scm.org/D1532
This covers both the vanilla repo -> lfs repo and largefiles -> lfs conversions.
The largefiles extension adds the requirement directly, because it has a
dedicated command to convert. Using the convert extension is better, because it
supports more features.
I'd like ideas about how to ensure that converting away from lfs works on all
files. (See comments in test-lfs.t)
The next patch will wrap the conversion code, in order to write out a
requirement for 'lfs' when appropriate. Wrapping convcmd.convertsink() in an
afterloaded callback works fine when the convert extension is enabled by the
user. The problem here is that lfconvert uses the convert extension, whether or
not it was formally enabled by the user.
My first attempt was to have lfs install an afterloaded callback that would wrap
the convert sink if convert was loaded, or wrap lfconvert if it wasn't. Then
the lfconvert override could install an afterloaded callback to try wrapping the
convert sink again, before calling the original lfconvert. But that breaks down
if largefiles can't load the convert extension on the fly. [1] Further, some
tests were failing with an error indicating that the size of the afterloaded
list changed while iterating it.
Yuya mentioned that maybe some bits of convert could be moved into core, but I'm
not sure where to draw that line. The convertsink() method depends on the list
of sinks, which in turn depends on the sink classes.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/108038.html
This seems like basic info to have, and will be used shortly when deciding
whether or not to wrap the class for lfs conversions.
The other option is to just add a function to each class. But this seems better
in that the strings aren't duplicated, and the constructor for most of these
will run even if the VCS isn't installed, so it's easier to catch errors.
Largefiles does the same thing (also delayed until the first largefile commit),
to prevent access to the repo without the extension. In the case of this
extension, not having the extension loaded while accessing an lfs file results
in cryptic errors about "missing processor for flag '0x2000'". If enabled
locally but not remotely, the cryptic error message is about no common
changegroup version. (It wants '03', which is currently experimental.)
The largefiles extension looks for any tracked file that starts with '.hglf/'.
Unfortunately, that doesn't work here. I didn't see any way to get the files
that were just committed, without doing a full status. But since there's no
secondary check on adding an lfs file once the extension is loaded and a
threshold set, the best practice is to only enable this locally on a repo that
needs it. That should minimize the unnecessary overhead for repos without an
lfs file.
