Summary:
The recent changes to the progress engine to work around locking bugs removed
the `clear` step of `progress.suspend`. This leads to garbled output when
a progress bar is ongoing. Restore it by adding a new lock method to the
engine.
Also add a `--with-output` option to `hg debugprogress` to test this.
Reviewed By: mitrandir77
Differential Revision: D12838415
fbshipit-source-id: 83ed516b528d0b0bbe37945141d50b50da00ac8e
Summary:
tweakdefaults renamed core hg's `grep` to `histgrep`, and added a `hg grep` that behaves more like `git grep`, searching the working copy. This diff folds those changes into core.
The config changes from
```
[tweakdefaults]
allowfullrepohistgrep = False
```
to
```
[histgrep]
allowfullrepogrep = False
```
Reviewed By: quark-zju
Differential Revision: D10435279
fbshipit-source-id: ad3d1da5824511a612111715e46119d70066050f
Summary:
Note that this is more aggressive than the tweakdefaults version; it doesn't allow named branches to be created or listed at all with the config set. As we want to delete named branches entirely, this seems reasonable.
I ported the `--new` flag, but made it optional, to make it easier to support both the core and tweakdefaults callers.
Saurabh Singh and I chatted with the releng team (Craig).
**tldr:** we can remove named branches from the UI but should keep the innards for now
Today the releng team doesn't make any branches (#continuous), but in the near-term future, they might either:
- create remote bookmarks in hg (similar to fbsource)
- create branches in SVN (which are then synced as hg branches by hgsubversion)
- We'll leave all the hgsubversion code to do this alone, just remove user-facing entry points
- They'll also need to be able to query for a commit's branch (`hg log -T '{branch}'` will still work)
- Once www is on hg, this possibility goes away and we can kill named branches for good
Reviewed By: ikostia
Differential Revision: D10401485
fbshipit-source-id: 6f2f3ae28af249bae1fdf782eb14fe7bfc472bb7
Summary:
This greatly simplifies the implementation, too.
*updatetotally() change:*
`hg up` now passes a brev of `None` if the `--inactive` flag was passed. This avoids activating the bookmark if one was passed. However, it still needs to deactivate the active bookmark, if there was one. After looking at the existing code, I think it was just wrong.
The rest of this is just cleanup.
Reviewed By: markbt
Differential Revision: D10376544
fbshipit-source-id: e5ad8aa01acab906db4d3fc09c6450e3c48b59fb
Summary:
This extension exposes only the `record` command which can be easily
moved to core. This commit achieves the same.
Reviewed By: ikostia
Differential Revision: D10360759
fbshipit-source-id: 25f0c46aa3fa9b19ab8ba03a6b4e8598bc003c7a
Summary:
The extension only offers one command i.e. `show` which can move into
core.
Reviewed By: ikostia
Differential Revision: D10302192
fbshipit-source-id: 9473ec8c80e52506e1b7de62b2c90a51c29419c1
Summary:
Parts of the treedirstate implementation were left in the extension. Since
treestate is now in core, and the two are intertwined, treedirstate should be
in core, too.
In doing so:
- Change the garbage collection behaviour to match that of treestate.
- Use the treestate config options for configuring repacking and garbage
collection.
- Make more of the code common.
Reviewed By: quark-zju
Differential Revision: D10258265
fbshipit-source-id: 89e82bc7662a3d1251fa9886751897cfc46cd66a
Summary:
Currently `hg bisect` asks to run test on all commits it picked as a result of bisection, even if the changes between last checked nodes and chosen one relate to the files, which are not in the sparse profile.
And so it updates to the one of such commits, shows that "0 files were updated" and asks to run tests.
In this diff I check next potential node (result of bisecting) if there are changes between last good commit/last bad commit and the node. And go further to the next bisection iteration if the node can be skipped (nothing was changed since last good commit in sparse profile's files, so we can assume that the node is good as well).
If there are changes on both sides: between bad and the node, good and the node, I ask to run tests.
Reviewed By: markbt
Differential Revision: D9629683
fbshipit-source-id: f8c5d82f7b44ac14a9190c846ee65d635e447af1
Summary: See the command docstring for the use-case.
Reviewed By: phillco, strager, singhsrb
Differential Revision: D9836447
fbshipit-source-id: 22ff603ce3e0cd95ea4e400ed24a96c0ea636e6b
Summary:
Previously, we would show root-relative paths. Now we show cwd-relative
paths unless the --root-relative flag is passed.
Reviewed By: phillco, farnz
Differential Revision: D9607987
fbshipit-source-id: 6c24c05317c165f88d2a83d6921d1520044a9b6e
Summary:
Recently there are a trend of questions about repo being locked. People usually
don't have enough debugging skills to find out what's going on. So let's add a
debug command to help them.
The implementation uses `osqueryi`, which perfectly solves the cross-platform
process handling headache. Note the well-known `psutil` Python library does not
seem to provide parent process information on Windows.
The `_rapply` function was backported from upstream mercurial.
Reviewed By: markbt
Differential Revision: D9443601
fbshipit-source-id: d26b3adfde1045ebd5bca1c6b1c93f0db147f9b0
Summary:
Add a new debug command to check whether any of the provided files
casecollide with any file in a revision's manifest.
Reviewed By: quark-zju
Differential Revision: D8165659
fbshipit-source-id: 9315ff052c9996888202961d168d20b834c22834
Summary:
Improve `makedirs` error message so it would be more helpful when there are
broken symlinks.
Differential Revision: D8108794
fbshipit-source-id: 08013022642efde946ef9d5c6b06b4763f4ad68f
Summary:
This would make tests run on treedirstate.
To avoid issues with Eden pulling from a non-eden treedirstate repo,
treedirstate is changed to be "always on" and disables itself on an eden repo.
The extension list is changed to a set for efficient `__contains__` test.
Reviewed By: phillco
Differential Revision: D7769804
fbshipit-source-id: d328fe51ef67c4730cfc53f43bdfc48c2765c541
Summary: Let's report that this lock cannot be read by Mercurial
Reviewed By: markbt
Differential Revision: D7653196
fbshipit-source-id: c5b7889cdde9c0ecc03a8c961aeba92f426648b1
Summary:
This allows people to silence hints as they like. It's done by modifying
user hgrc.
Reviewed By: markbt
Differential Revision: D7392133
fbshipit-source-id: 1365294217db92dfb3a0c81332a9fefd164795d4
Summary:
Add the ability to set a `formatfunc` on a progres bar, which formats the
numbers used. Use `util.bytecount` as a format function in the places
where we have progress bars in numbers of bytes.
Reviewed By: quark-zju
Differential Revision: D7355232
fbshipit-source-id: 117c7035d46d47259cdfd70b80438cc6f4615977
Summary:
This adds the ability to specify a config file to be used during the
command. This is useful during clones for letting the clone command use the
given repositories system specified repo-specific hgrc file.
Reviewed By: quark-zju
Differential Revision: D7311576
fbshipit-source-id: a97d8ebada2e0bea27c75a7650df8ede00dc10c6
Summary:
This adds `progress.bar`, which is a context manager that provides a
time-updated progress bar, analogous to `progress.spinner`.
Reviewed By: ryanmce
Differential Revision: D7211895
fbshipit-source-id: be07d363f10c09164e2324d31a71a7c795257c8a
Summary:
Add a new `--only-files-in-revs` option to `hg diff`. This filters the files
that are considered down to the set of files that are touched in either of the
two revisions.
Reviewed By: ryanmce
Differential Revision: D7070102
fbshipit-source-id: b9140cd3a212af9554ef5b76785210c1dbba8ee0
Summary:
Currently, commits adding LFS files are not verified server-side since the LFS
extension explicitly skips hash checking during unbundle, to avoid overhead
downloading/reading LFS objects.
We'd like those commit hashes to be verified. However, the existing verify
command does not scale with a huge repo. So let's add `verify -r REV` support
to be able to incrementally verify a repo.
Reviewed By: quark-zju
Differential Revision: D6947227
fbshipit-source-id: 6ffda3a814822942630339fc7de62c3fcb284fda
Summary:
This allows us to specify `-p 0 --port-file X` to get the port assigned in
an atomic way. So there won't be "server failed to start" caused by race
conditions in tests.
Reviewed By: DurhamG
Differential Revision: D6925397
fbshipit-source-id: 5bbb61b7eb2695f0a673afdb0730d2a61827f8b3
Summary:
This is similar to `debugdata`, but instead of taking a file revision (or
file node in remotefilelog's case), it takes a revset.
This is more useful practically, since the user would know commit hashes
easily but file nodes are hidden from the UI.
This is intended to make it easier to investigate LFS contents.
Reviewed By: DurhamG, ryanmce
Differential Revision: D6891770
fbshipit-source-id: 415da9b773c30830a48c09eda9f1854c416e3222
Summary:
Since we have `debugbuilddag` as a builtin command, and `drawdag` is
pretty useful for writing clean test cases. Let's inline it. This would
simplify many tests since `drawdag=..." is no longer needed.
Reviewed By: DurhamG
Differential Revision: D6827925
fbshipit-source-id: b749f57fd5c55b2cb000dd2da2c2f9bc2386a519
Summary:
It's pretty handy. The implementation is simple and clean. So move it from
contrib and enable it by default. "import"s are adjusted to make the module
checker happy.
Security and UX wise, since we have `--debugger` already, adding another
REPL seems fine.
Test Plan: Ran all tests
Reviewers: phillco, #mercurial
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6741283
Signature: 6741283:1516225662:ddc19a663e7ecef2a1fdaa5041f308dc838a8471
Recently hg-ssh was changed to block writes via in-memory hook configuration
instead of by passing config hooks, and dispatch.py blocks any invocation of hg
serve --stdio that has options passed. We have infrastructure that sets up read
only serve processes without using hg-ssh, and it was broken by this change.
Let's add a --read-only option to hg serve so non-hg-ssh solutions can still
launch hg in read-only mode. This makes it also work with non-stdio serve
processes as well.
(grafted from 7a0ed9aad8526f689343a5a02aa4a66e5f3be1f2)
(grafted from bf33f750447d8b0dfeae2a311e1d1eb93e19d6a0)
(grafted from 9ada6a6e4ac2a92325592cd58edd9160e17c9e31)
(grafted from 50e676e99c3b7cc929ceaaebbd3c684a8a58f9d8)
(grafted from 01833a49fa4dca204dc0e606f21279530925307c)
(grafted from 301af2e1a42fe912acf90ae9a87ca6a20ce5cd5d)
(grafted from 6ae2eaad3edbfdfb04ac5880a86341e69980529c)
(grafted from fcdedd417b29d28797840fc2393e0ff846fa54c8)
(grafted from ddda3705adfb2ac103f506d694d2b30028dfaca9)
(grafted from 138e3cf3bc394c4ff507341a390e1876c7104042)
(grafted from f8073d595e87086213525dbb642962b84158ee9a)
(grafted from 96bac04dc722030250a53616f0fb55125829f25e)
(grafted from 2aeed48cc3b3324b564343d8515aed1ecec69b14)
(grafted from 4fb2e02a273c868febdae9530b0a07a53a0e92a7)
(grafted from c57b28835f0b880c075d5b8aa99ddb9da54b21b1)
(grafted from 35fd78b021bec96db63e8dd99f98efc3b2342380)
(grafted from 9ac14f96c9a82068f07a709374f359283c206791)
(grafted from 4b64c191a9aacd52ea58ae8ec943605667759398)
(grafted from 1db390a79e32db12dde7a225e26b86ed245f9473)
(grafted from 9a999ed1ce50af8e5fa03dc270488c37304d8c94)
(grafted from b6791f2eb83f176192c9df50c736bc4c54fab5a6)
(grafted from 4b6e87c5be38d9971399e4ad989e4261f283b93a)
(grafted from ae660c075b4af0849d1ff5d36404ef66aeea9933)
(grafted from ff0f3bf0834b38a527654495369cd538ca8744f4)
(grafted from bff8177767c9023295ff93bc520114bb909952a8)
(grafted from 05a833e4071b9da7b447669f6bd8a3f62c1d3c27)
(grafted from be8ab299731fb8295efbe10a014798c7a177d4a0)
(grafted from beec2bc2ebd9eaf7093bba5fca8fef07c669d970)
(grafted from 03d88ba3cd8795d17a99dc1b50ac55e1937d38e1)
(grafted from 92a33bc0d275a96c61553f8bccefcd32f1360931)
(grafted from 3d37833f54e37356f3e32db2ad8fb2ffe4fa14f2)
(grafted from 77fa3393787a9410e14afc26465abb5561253075)
(grafted from 9d908f86cc7986c167cef5cdccaabb565fd2bc04)
(grafted from 0dbc2023c42f72aea6b608e5111725163dcbb64b)
(grafted from 3acf4e9bb718617efaf31abcba583b9b7be2559d)
(grafted from c671696a06e418f5f040427efb3e51fe4c9fa6cd)
(grafted from 309f11e682eb3c6fa497bf767cbcbef3b0dbaf4b)
(grafted from 4f828ef4b70a6a16fe747d5f6393042bff204b5e)
(grafted from 71193e84a71d029dedc744882978285cbe5722e6)
(grafted from 2929832c61c9727bd884f94da5afa29e80334a96)
(grafted from 2ff8a9f1761f82ffa8ebd2a96d86f7de7c712d9c)
(grafted from b438cb1e6cff36e7e197da7669def8a5e528053c)
(grafted from a9ed103481b779af9e160d2b81a9bfe81cc7d173)
(grafted from d139e95d22dc811002dafef1ecaac5dac99825fe)
(grafted from b4e41a9f2c3a6328ada72810407686d11833347c)
(grafted from 2b3826c7b3bdf669b397f1ad31ae106a05d7b05b)
(grafted from 23737fb5e1d6874cf79a1eb841dd1614c0295a1b)
(grafted from 69588396b17d3dafeece8bc9e2101559d871d9fb)
(grafted from b3252a277a53b1657e6bcf31359b413d2becffcc)
(grafted from 12c8e6062d34d4d6cf0b0128084278800a1ed8f7)
(grafted from 8ce5c67748afbe6e82fc3f822e35ddc58cb03694)
(grafted from b0f656426efcf9a70386b1c781507f40ab95af49)
(grafted from 147ae96993dcffbed2f39f31795ef3d60631d43f)
(grafted from 2ecb34a565accf638e6004c59aa5b2d2361f9428)
(grafted from 6bfc53cd4c479b4e789d4086a2c7c2f4045a288f)
(grafted from bf73f92394a079928db6d4b0b3e7aa78448af91a)
(grafted from b69a654342339eb740527fc84af523eb53edeb71)
(grafted from 3f090f44e8a33cde8d5708454a5292d0976269e6)
(grafted from ac4432275d3b750405e53f67b1267579764f4fee)
(grafted from dbfd0bce0eded53dc7d824393f03ddd2f2e693fb)
(grafted from bf7087d072ca6c5d5dac2ddef4c43339d02f6133)
(grafted from b9d63feb8c90f83e74f3e9a89328419c81088082)
(grafted from 718e93a4e545f3e16d09c66f210a567427f1068a)
(grafted from e0ba57c8bf13ccc45b7eaa62d64e03038cd002ad)
(grafted from 5c849011421ad00ef190c2bf15c640656424f681)
(grafted from e833de714167fe6039b42f1cd1890b0470a32ea2)
(grafted from 480872890137130564910a29ed8ef3890810f0c4)
(grafted from 6224dc455a24542cf7d55721fceb14a08e92d391)
(grafted from 24ced5d2b0d6fb837a3994a80ef808e29f62ccc5)
(grafted from 452eb5c8624cc22867fafa692c6c7905e46da27a)
(grafted from cdc9f1b121878c26c986eca2233b5d03ea50ad74)
(grafted from 8b3a45fe3a612fdbee3a1f291f41bfaadfd16a6f)
(grafted from 2a07c0b3cb9785a9f8d5d669b885044e4d4544b1)
(grafted from 56d892df53cfdf3a13f38cd386a437ea59ef0d77)
(grafted from b63c65fad2d28a86a3bc3871d58e45019b11e6a1)
(grafted from 8618bd56f309543d8577000a4310fdf8648f1087)
(grafted from e04c7ddddc5cc40d6347d2336b81d5be2289243e)
(grafted from 5951fe6318d02a9b739f0174f3aecc3d5eead31c)
(grafted from 0f4d380f641a55791ca9eef13cd49da24cf40a7a)
(grafted from d7ecf3376e572d77b670cbe2184370b08d38dcf7)
(grafted from a75534c9e6d7a481303096e44e265593fb5b0b2f)
The command displays basic data about all format variants registered for repo
upgrades. This gives a quick way to peek into a repository format.
The 'fm.write()' calls are very independent because more data will be added in
later changeset. Having more separate call make the later patch clearer.
Currently, the push discovery first determines the full set of common nodes
before looking into what changesets are outgoing. When pushing a specific
subset, this can lead to pathological situations where we search for the status
of thousand of local heads that are unrelated to the requested pushes.
To fix this, we need to teach the discovery to ignores part of the graph. Most
of the necessary pieces were already in place. This changeset just makes them
available to higher level API and tests them.
Change actually impacting pushes are coming in a later changeset.
This new debugcommand prints the capabilities of any remote in a human friendly
way. Improved bundle2 capabilities support will be introduced in the next
changesets.
We add an experimental -L/--line-range option to 'hg log' taking file patterns
along with a line range using the (new) FILE,FROMLINE-TOLINE syntax where FILE
may be a pattern (matching exactly one file). The resulting history is similar
to what the "followlines" revset except that, if --patch is specified,
only diff hunks within specified line range are shown.
Basically, this brings the CLI on par with what currently only exists in hgweb
through line selection in "file" and "annotate" views resulting in a file log
with filtered patch to only display followed line range.
The option may be specified multiple times and can be combined with --rev and
regular file patterns to further restrict revisions. Usage of this option
requires --follow; revisions are shown in descending order and renames are
followed. Only the --graph option is currently not supported.
The UI is the result of a consensus from review feedback at:
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-October/106749.html
The implementation spreads between commands.log() and cmdutil module.
In commands.log(), the main loop may now use a "hunksfilter" factory (similar
to "filematcher") that, for a given "rev", produces a filtering function
for diff hunks for a given file context object.
The logic to build revisions from -L/--line-range options lives in
cmdutil.getloglinerangerevs() which produces "revs", "filematcher" and
"hunksfilter" information. Revisions obtained by following files' line range
are filtered if they do not match the revset specified by --rev option. If
regular FILE arguments are passed along with -L options, both filematchers are
combined into a new matcher.
.. feature::
Add an experimental -L/--line-range FILE,FROMLINE-TOLINE option to 'hg log'
command to follow the history of files by line range. In combination with
-p/--patch option, only diff hunks within specified line range will be
displayed. Feedback, especially on UX aspects, is welcome.
--uncompressed isn't a very good name and its description in the
help documentation isn't very useful. We refer to this concept as
"stream clones" in a number of places. I think it makes sense to
change the user-facing argument to use the mode --stream. So this
commit does that.
We keep --uncompressed around for backwards compatibility.
While we're here, we overhaul the help docs for streaming clones
to be somewhat useful.
All tests have been updated to reflect the new preferred --stream
argument. A test for backwards compatibility of --uncompressed has
been added.
.. bc::
`hg clone --stream` should now be used instead of --uncompressed.
--uncompressed is marked as deprecated and is an alias for --stream.
There is no schedule for elimination of --uncompressed.
Differential Revision: https://phab.mercurial-scm.org/D864
Add an option that only ignores whitespaces at EOL. The name of the option is
the same as Git.
.. feature::
Added `--ignore-space-at-eol` diff option to ignore whitespace differences
at line endings.
Differential Revision: https://phab.mercurial-scm.org/D422
pushvars extension in fbext adds a --pushvars flag to push command using which
one send strings to server which becomes environment variables there prepended
with HG_USERVAR_. These variables can then be used to run hooks on the server.
The extension is moved directly to core and unbundling of the strings and
converting them to environment variables at server is disabled by default for
security reasons. One can turn that on by following config:
[push]
pushvars.server = true
This patch also adds the test for the extension.
Differential Revision: https://phab.mercurial-scm.org/D210
This adds an experimental flag -t/--terse which will terse the output. The terse flag
will respect other flags which filters the output. The flag takes a string
whose value can be a subsequence of "marduic" (the order does not matter here.)
Ignored files are not considered while tersing unless -i flag is passed or 'i'
is there is the terse flag value.
The flag is experimental for testing as there may be cases which will produce
strange results with the flag. We can set the terse on by default by simply
passing 'u' to the cmdutil.tersestatus().
This patch also adds a test file with tests covering the new feature.
This is only useful on Windows, and avoids the need to use Internet Explorer to
build the certificate chain. I can see this being extended in the future to
print information about the certificate(s) to help debug issues on any platform.
Maybe even perform some of the python checks listed on the secure connections
wiki page. But for now, all I need is 1) a command that can be invoked in a
setup script to ensure the certificate is installed, and 2) a command that the
user can run if/when a certificate changes in the future.
It would have been nice to leverage the sslutil library to pick up host specific
settings, but attempting to use sslutil.wrapsocket() failed the
'not sslsocket.cipher()' check in it and aborted.
The output is a little more chatty than some commands, but I've seen the update
take 10+ seconds, and this is only a debug command.
Add a closest argument to successorssets changing the definition of latest
successors.
With "closest=false" (current behavior), latest successors are "leafs" on the
obsmarker graph. They don't have any successor and are known locally.
With "closest=true", latest successors are the closest locally-known
changesets that are visible in the repository or repoview. Closest successors
can be then obsolete, orphan.
This will be used in a later patch to show the closest successor of
changesets with the successorssets template.
This is based on a patch proposed last year by Mathias De Maré[1], with a few
changes.
- Tags and bookmarks are now formatted lists, for more flexible queries.
- The templater is populated whether or not [-nibtB] is specified. (Plain
output is unchanged.) This seems more consistent with other templated
commands.
- The 'id' property is a string, instead of a list.
- The parents of 'wdir()' have their own list of attributes.
I left 'id' as a string because it seems very useful for generating version
info. It's also a bit strange because the value and meaning changes depending
on whether or not --debug is passed (short vs full hash), whether the revision
is a merge or not (one hash or two, separated by a '+'), the working directory
or not (node vs p1node), and local or not (remote defaults to tip, and never has
'+'). The equivalent string built with {rev} seems much less useful, and I
couldn't think of a reasonable name, so I left it out.
The discussion seemed to be pointing towards having a list of nodes, with more
than one entry for a merge. It seems simpler to give the nodes a name, and use
{node} for the actual commit probed, especially now that there is a virtual node
for 'wdir()'.
Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes.
I'm not sure if the plan is to fill in all of the context attributes in these
items, or if these nested items should simply be made {p1node} and {p1rev}.
I used ':' as the tag separator for consistency with {tags} in the log
templater. Likewise, bookmarks are separated by a space for consistency with
the corresponding log template.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
