- Nov 02, 2020
-
-
Augie Fackler authored
-
durin42 authored
-
durin42 authored
-
- Oct 29, 2020
-
-
Dan Villiom Podlaski Christiansen authored
Running `make update-pot` currently fails with the following error: xgettext: mercurial/metadata.py:1: Unknown encoding "utf8". Proceeding with ASCII instead. xgettext: Non-ASCII string at mercurial/metadata.py:311. Please specify the source encoding through --from-code or through a comment as specified in http://www.python.org/peps/pep-0263.html. Differential Revision: https://phab.mercurial-scm.org/D9260
-
Dan Villiom Podlaski Christiansen authored
`itervalues()` is only available on Python 2. Since this script doesn't currently refer to the main Mercurial modules, and as a result doesn't have easy access to the `pycompat` module, I simply changed it to use `value()` instead. Although this allocates a list on Python 2, I'd consider that acceptable for a utility script; Mercurial doesn't have all _that_ many commands anyway. Differential Revision: https://phab.mercurial-scm.org/D9259
-
Martin von Zweigbergk authored
The same procedure as every year^Wcycle. Differential Revision: https://phab.mercurial-scm.org/D9263
-
- Oct 13, 2020
-
-
Pierre-Yves David authored
See test documentation for details. This is yet another corner case for copy tracing. Differential Revision: https://phab.mercurial-scm.org/D9200
-
- Oct 21, 2020
-
-
Jörg Sonnenberger authored
The memorytop function uses Python's tracemalloc module to show the source lines / backtraces with the largest remaining allocations. This allows identifying the origins of active memory by placing calls in strategic locations. Allocations from C extensions will show up as long as they are using the Python allocators. Differential Revision: https://phab.mercurial-scm.org/D9236
-
- Oct 29, 2020
-
-
Martin von Zweigbergk authored
I left out branches and custom namespaces on purpose from D9252 because I figured that people like us (Google) who have custom namespaces can also have custom configs. However, I just realized that this makes everyone with the topic extension lose the topic they've had in rebase output for a long time (ever since someone was nice enough to add it in D741). Sorry about the churn. The more generic template couldn't easily keep the "log.bookmark" label in the template because the namespace is called "bookmarks" (plural). That means that we can't be compatible with users' existing configs for "log.bookmark", so I decided to change the labels to be in a brand-new "oneline-summary" namespace. Differential Revision: https://phab.mercurial-scm.org/D9262
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9258
-
Martin von Zweigbergk authored
-
- Oct 24, 2020
-
-
Matt Harbison authored
I noticed after doing an update from an obsolete revision with a dirty wdir that the obsolete commit stayed visible for no obvious reason. It was decided in 85b03b1e4715 not to clear mergestate once all of the conflicts were resolved, in order to allow re-resolving. Since the point of pinning the obsolete parents was to allow resolving in the first place (aaeccdb6e654), it makes sense to also gate it on whether or not there are any remaining files to resolve. This might result in pinning again if files are marked unresolved again, but that seems reasonable, given that it still solves the original issue. Note that this isn't purely cosmetic- pushing with a pinned obsolete revision is likely to cause complaints about pushing multiple heads or other unexpected errors. So the faster it comes out of that state, the better. Differential Revision: https://phab.mercurial-scm.org/D9248
-
- Oct 28, 2020
-
-
Dan Villiom Podlaski Christiansen authored
Differential Revision: https://phab.mercurial-scm.org/D9256
-
- Oct 23, 2020
-
-
Yuya Nishihara authored
I initially thought this is a py3-compat bug of passwordmgr._writedebug(), but actually returning (None, str) pair is wrong at all. HTTP authentication would continue with user="None" in that case. Since registering a password of user=None should also be wrong, this patch simply adds early return.
-
Yuya Nishihara authored
Spotted while writing tests for the issue6425. The default value may be None.
-
- Oct 29, 2020
-
-
Dan Villiom Podlaski Christiansen authored
I noticed when pulling with hg-git in a repository that already had the changes, but pulled from another Mercurial repository. This meant that hg-git would re-create exact matches of the changesets, and if they were public, they'd get reverted to drafts. Differential Revision: https://phab.mercurial-scm.org/D9253
-
- Oct 17, 2020
-
-
Yuya Nishihara authored
I'm a bit confused while reading 03690079d7dd, which says "a destination file", but the code loops over matched files.
-
- Oct 13, 2020
-
-
Matt Harbison authored
This excludes the --collapse case because degenerating to p1 is almost certainly as wrong as leaving the old hashes in place. I expect most people to amend the message explicitly when using that. Differential Revision: https://phab.mercurial-scm.org/D9229
-
- Oct 23, 2020
-
-
Martin von Zweigbergk authored
AFAICT, `cmdutil.rendertemplate()` always returns bytes (never e.g. `None`), so we don't need to fall back to empty (byte-)string. The fallback has been there since the code was added in 11c076786d56 (histedit: add templating support to histedit's rule file generation, 2019-01-29). Differential Revision: https://phab.mercurial-scm.org/D9244
-
- Oct 20, 2020
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9233
-
- Oct 19, 2020
-
-
Jörg Sonnenberger authored
The core internals either use revision sets already or can trivially use them. Use the new interface in cg1unpacker.apply to avoid materializing the list of all new nodes as it is normally just a revision range. This avoids about 67 Bytes / changeset on AMD64 in peak RSS. Differential Revision: https://phab.mercurial-scm.org/D9232
-
- Oct 18, 2020
-
-
Jörg Sonnenberger authored
The addgroup() interface currently doesn't allow the caller to keep track of duplicated nodes except by looking at the returned node list. Add an optional second callback for this purpose and change the return type to a boolean. This allows follow-up changes to use more efficient storage for the node list in places that are memory-sensitive. Differential Revision: https://phab.mercurial-scm.org/D9231
-
- Oct 07, 2020
-
-
Pulkit Goyal authored
I am trying to fix a breakage where somehow we end up getting a node of 12 length from `getfnode()`. Understanding the hgtagsfnodescache code, it seems highly unlikely that it can happen unless one of `mctx.readfast().get()` or `ctx.filenode()` is returning a node of 12 length. For safety, I think it's better to add a check to make sure that record which we are parsing is of same length we are expecting otherwise we consider that as invalid record. Differential Revision: https://phab.mercurial-scm.org/D9169
-
- Oct 14, 2020
-
-
Pierre-Yves David authored
For automatic clonebundles generation I need to pass arbitrary large amount of data to the process (eg: common nodes, target nodes). I am updating the `runbgcommand` to allow for this. Previously not stdin input was possible, now, one can provide raw bytes and they will be feed to the command through an unnamed temporary files. Differential Revision: https://phab.mercurial-scm.org/D9212
-
Pierre-Yves David authored
I am about to add more reference to it, so I would rather have it an explicit constant. This allow to unify various call too. Differential Revision: https://phab.mercurial-scm.org/D9209
-
- Oct 15, 2020
-
-
Pierre-Yves David authored
In the process on general clone bundle automatically, we need to make some function available more widely. This is a good opportunity to extract a significant amount of code from `mercurial.exchange` into a new `mercurial.bundlecaches`. This make `mercurial.exchange` move under the 3K line range (hooray…). The module is called `bundlecaches` because I expect it to be eventually useful for more than just clone bundle (like pull bunbles). Differential Revision: https://phab.mercurial-scm.org/D9208
-
- Jul 01, 2020
-
-
Pulkit Goyal authored
Previous patches add a safe mode for sharing repositories which involve sharing of source requirements and config files. In certain situations we might need to add a config to source repository which we does not want to share. For this, we add a `.hg/hgrc-not-shared` which won't be shared. This also adds a `--non-shared` flag to `hg config` command to see the non-shared config. Differential Revision: https://phab.mercurial-scm.org/D8673
-
- Sep 18, 2020
-
-
Pulkit Goyal authored
It seems to me now that there are two steps when config is loaded: 1) on dispatch 2) repository object creation Recent patches added functionality that there can be shares in share-safe mode where config of the source repository is shared with the the shares. However we missed adding logic to read the source config on dispatch. This leads to extensions not being loaded on dispatch and hence extensions command not being recognized. This patch fixes it by reading the shared source config on dispatch. Differential Revision: https://phab.mercurial-scm.org/D9047
-
Pulkit Goyal authored
When we are using share-safe and loading source repository config, we are still not loading the extensions which are enabled in the source repository. This patch demonstrates the bug. Meanwhile it also shows how unreliable `hg debugextensions` is. Differential Revision: https://phab.mercurial-scm.org/D9046
-
- Oct 09, 2020
-
-
Pierre-Yves David authored
But explicitly with the special case early, laying out the various case become simpler. (The initial motivation was to make some future lifetime error simpler). Differential Revision: https://phab.mercurial-scm.org/D9203
-
- Oct 20, 2020
-
-
Jörg Sonnenberger authored
For a large repository, this reduces the number of filelog instances and associated data a lot. For a 1% speed penalty, it reduces peak RSS by 20% for the full NetBSD test repository. Differential Revision: https://phab.mercurial-scm.org/D9235
-
- Oct 14, 2020
-
-
Martin von Zweigbergk authored
I also removed some unnecessary `#if no-changeset` where the `#else` was the same :P Differential Revision: https://phab.mercurial-scm.org/D9204
-
- Oct 22, 2020
-
-
Martin von Zweigbergk authored
When the config parser raises a ParseError, it uses the line that failed to parse as the error message. It doesn't currently tell the user anything about why it failed to parse. b13b99d39a46 (config: highlight parse error caused by leading spaces (issue3214), 2014-03-16) added a checked based on the error *message* having leading spaces. That has worked fine because only the config parser uses the line itself as error message (I think the revset and fileset parsers use more user-friendly proper messages). It still feels like a hack. Let's make the config parser give a useful message about leading whitespace instead. We should ideally follow up with more useful messages for other parse errors in config files. Differential Revision: https://phab.mercurial-scm.org/D9241
-
Martin von Zweigbergk authored
As with similar previous patches, this is to improve readability. Differential Revision: https://phab.mercurial-scm.org/D9240
-
- Oct 20, 2020
-
-
Martin von Zweigbergk authored
StorageError already provides the same definition. Differential Revision: https://phab.mercurial-scm.org/D9234
-
- Oct 16, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9218
-
- Oct 27, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9255
-
Martin von Zweigbergk authored
This means that the `phabricator.node` and `phabricator.desc` color configs will no longer be respected, but `log.changeset` and `log.desc` will be respected instead. Differential Revision: https://phab.mercurial-scm.org/D9254
-
Martin von Zweigbergk authored
This removes the default template in rebase and switches to a centrally defined template. I've simplified it a bit to avoid the conditional parenthesis. I've also added labels so the different parts can be easily colored. The template is somewhat similar to what we've used internally at Google for a few years. I'm happy to change the template if others have opinions. Should we reuse the `color.log.` names as I have? Differential Revision: https://phab.mercurial-scm.org/D9252
-
- Oct 23, 2020
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9251
-