Thu, 29 Oct 2020 13:29:05 +0100 relnotes: mention improved memory use and underlaying API changes
Joerg Sonnenberger <joerg@bec.de> [Thu, 29 Oct 2020 13:29:05 +0100] rev 45795
relnotes: mention improved memory use and underlaying API changes Differential Revision: https://phab.mercurial-scm.org/D9258
Thu, 29 Oct 2020 00:17:12 -0700 branching: merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Oct 2020 00:17:12 -0700] rev 45794
branching: merge with stable
Sat, 17 Oct 2020 21:57:21 +0900 help: update command synopsis to clarify "cp --forget" only takes destinations
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Oct 2020 21:57:21 +0900] rev 45793
help: update command synopsis to clarify "cp --forget" only takes destinations I'm a bit confused while reading 03690079d7dd, which says "a destination file", but the code loops over matched files.
Tue, 13 Oct 2020 14:16:21 -0400 rebase: update commit hash references in the new commits
Matt Harbison <matt_harbison@yahoo.com> [Tue, 13 Oct 2020 14:16:21 -0400] rev 45792
rebase: update commit hash references in the new commits 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
Thu, 22 Oct 2020 23:35:04 -0700 histedit: drop fallback to empty string from rendertemplate()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 23:35:04 -0700] rev 45791
histedit: drop fallback to empty string from rendertemplate() 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
Tue, 20 Oct 2020 17:32:45 +0200 phases: convert registernew users to use revision sets
Joerg Sonnenberger <joerg@bec.de> [Tue, 20 Oct 2020 17:32:45 +0200] rev 45790
phases: convert registernew users to use revision sets Differential Revision: https://phab.mercurial-scm.org/D9233
Mon, 19 Oct 2020 02:54:12 +0200 phases: allow registration and boundary advancement with revision sets
Joerg Sonnenberger <joerg@bec.de> [Mon, 19 Oct 2020 02:54:12 +0200] rev 45789
phases: allow registration and boundary advancement with revision sets 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
Sun, 18 Oct 2020 22:18:02 +0200 revlog: extend addgroup() with callback for duplicates
Joerg Sonnenberger <joerg@bec.de> [Sun, 18 Oct 2020 22:18:02 +0200] rev 45788
revlog: extend addgroup() with callback for duplicates 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
Wed, 07 Oct 2020 14:26:47 +0530 tags: add safety check for len(record) while reading hgtagsfnodescache
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 07 Oct 2020 14:26:47 +0530] rev 45787
tags: add safety check for len(record) while reading hgtagsfnodescache 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
Wed, 14 Oct 2020 17:52:18 +0200 procutil: allow to specify arbitrary stdin bytes to runbgcommand
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Oct 2020 17:52:18 +0200] rev 45786
procutil: allow to specify arbitrary stdin bytes to runbgcommand 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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip