Wed, 04 Mar 2020 10:25:07 -0500 phabricator: make `hg phabread` work outside of a repository
Matt Harbison <matt_harbison@yahoo.com> [Wed, 04 Mar 2020 10:25:07 -0500] rev 44448
phabricator: make `hg phabread` work outside of a repository This is similar to 16312ea45a8b and 2513f0f70a26- we don't need a repo, but will load .hg/hgrc if inside one. Differential Revision: https://phab.mercurial-scm.org/D8214
Sun, 16 Feb 2020 15:06:20 -0500 phabricator: refactor `phabread` to write all patches at once
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Feb 2020 15:06:20 -0500] rev 44447
phabricator: refactor `phabread` to write all patches at once This will be necessary to create a first class `phabimport` command. That command requires a transaction, and will import all named patches within a single transaction. But if Phabricator queries also happen within the transaction, that leaves open the chance that an exception is raised, the transaction is abandoned, and the next command that is run will complain about needing to run `hg recover`. Differential Revision: https://phab.mercurial-scm.org/D8135
Mon, 17 Feb 2020 13:14:44 -0500 phabricator: make `hg phabupdate` work outside of a repository
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:14:44 -0500] rev 44446
phabricator: make `hg phabupdate` work outside of a repository This is similar to 16312ea45a8b- we don't need a repo, but will load .hg/hgrc if inside one. Differential Revision: https://phab.mercurial-scm.org/D8208
Mon, 17 Feb 2020 13:28:40 -0500 phabricator: pass ui instead of repo to `userphids()`
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:28:40 -0500] rev 44445
phabricator: pass ui instead of repo to `userphids()` Also not a repository operation. Differential Revision: https://phab.mercurial-scm.org/D8207
Mon, 17 Feb 2020 13:08:01 -0500 phabricator: pass ui instead of repo to `querydrev()`
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:08:01 -0500] rev 44444
phabricator: pass ui instead of repo to `querydrev()` Also not a repository operation. Differential Revision: https://phab.mercurial-scm.org/D8206
Mon, 17 Feb 2020 13:01:16 -0500 phabricator: pass ui instead of repo to `readpatch()`
Matt Harbison <matt_harbison@yahoo.com> [Mon, 17 Feb 2020 13:01:16 -0500] rev 44443
phabricator: pass ui instead of repo to `readpatch()` This makes it a little clearer that it isn't a repository operation. Differential Revision: https://phab.mercurial-scm.org/D8205
Mon, 02 Mar 2020 14:36:20 -0500 logtoprocess: avoid traceback when running long commands
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 02 Mar 2020 14:36:20 -0500] rev 44442
logtoprocess: avoid traceback when running long commands $ hg log -r "present($(yes | tr -d '\n' | head -c 130000))" "$(yes | tr -d '\n' | head -c 5000)" --config extensions.logtoprocess= --config logtoprocess.commandfinish=whatever Traceback (most recent call last): File "/usr/bin/hg", line 67, in <module> dispatch.run() File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 111, in run status = dispatch(req) File "/usr/lib64/python2.7/site-packages/mercurial/dispatch.py", line 290, in dispatch canonical_command=req.canonical_command, File "/usr/lib64/python2.7/site-packages/mercurial/ui.py", line 1991, in log logger.log(self, event, msg, opts) File "/usr/lib64/python2.7/site-packages/hgext/logtoprocess.py", line 72, in log procutil.runbgcommand(script, fullenv, shell=True) File "/usr/lib64/python2.7/site-packages/mercurial/utils/procutil.py", line 597, in runbgcommand b'error running %r: %s' % (cmd, os.strerror(returncode)), OSError: [Errno 7] error running 'whatever': Argument list too long This can happen if you pass a bunch of filenames to hg commit, for instance. This is due to a size limit on individual env vars (on linux, but I imagine there are similar limits in other OSes): $ FOO=$(yes | head -c 131000) /usr/bin/true $ FOO=$(yes | head -c 132000) /usr/bin/true -bash: /usr/bin/true: Argument list too long I propose to avoid this by truncating the message. I didn't make the limit configurable as it doesn't seem particularly convenient to customize this. I'm not sure if various OSes would want radically different limits here? Differential Revision: https://phab.mercurial-scm.org/D8203
Mon, 24 Feb 2020 17:57:57 +0100 rust-cpython: make `NonNormalEntires` iterable to fix `fsmonitor` (issue6276)
Raphaël Gomès <rgomes@octobus.net> [Mon, 24 Feb 2020 17:57:57 +0100] rev 44441
rust-cpython: make `NonNormalEntires` iterable to fix `fsmonitor` (issue6276) This fixes a bug when using `fsmonitor` that tries to iterate on the non normal set, by adding a shared iterator interface. Differential Revision: https://phab.mercurial-scm.org/D8143
Sat, 07 Sep 2019 14:50:39 +0200 hgext: start building a library for simple hooks
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Sep 2019 14:50:39 +0200] rev 44440
hgext: start building a library for simple hooks Many workflows depend on hooks to enforce certain policies, e.g. to prevent forced pushes. The Mercurial Guide includes some cases and Google can help finding others, but it can save users a lot of time if hg itself has a couple of examples for further customization. Differential Revision: https://phab.mercurial-scm.org/D6825
Tue, 25 Feb 2020 20:27:39 -0500 exchange: turn on option that makes concurrent pushes work better
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 25 Feb 2020 20:27:39 -0500] rev 44439
exchange: turn on option that makes concurrent pushes work better The motivation is simply to make hg work better out of the box. This is a slight backwards compatibility break, because client extensions could have assumed that the list of heads the client sees during discovery will be the list of heads during the entirety of the push. It seems unlikely to matter, and not worth mentioning. There's a fair amount of diff in tests, but this is just due to sending a few more bytes on the wire, except for test-acl.t. The extra "invalid branch cache" lines in test-acl.t don't seem to indicate a problem: the branchcache now get computed during the bundle application (because of the check:updated-heads bundle part), but doesn't get rolled back when transactions rollback, thus causing a message in the next operation computing the branch cache. Before this change, I assume the branchcache was only computed on transaction commit, so not computed at all when the transactions roll back, thus no messages. Differential Revision: https://phab.mercurial-scm.org/D8202
Mon, 02 Mar 2020 15:34:51 -0500 update: simplify slightly
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 02 Mar 2020 15:34:51 -0500] rev 44438
update: simplify slightly Differential Revision: https://phab.mercurial-scm.org/D8204
Sun, 01 Mar 2020 21:16:45 -0500 help: clarify behavior of server.concurrent-push-mode
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 01 Mar 2020 21:16:45 -0500] rev 44437
help: clarify behavior of server.concurrent-push-mode So it doesn't seemingly say that old clients cannot talk to server configured with concurrent-push-mode=check-related. They can, they just don't get the benefit. Differential Revision: https://phab.mercurial-scm.org/D8201
Fri, 28 Feb 2020 10:30:18 -0800 commit: error out on unresolved files even if commit would be empty
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 10:30:18 -0800] rev 44436
commit: error out on unresolved files even if commit would be empty Differential Revision: https://phab.mercurial-scm.org/D8195
Fri, 28 Feb 2020 10:49:13 -0800 tests: add test of committing with conflicts but no changes in wdir
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Feb 2020 10:49:13 -0800] rev 44435
tests: add test of committing with conflicts but no changes in wdir I'm about to change the behavior slightly here, so let's have a test that shows that. Differential Revision: https://phab.mercurial-scm.org/D8194
Fri, 28 Feb 2020 00:17:26 +0100 transaction: clarify the logic around pre-finalize/post-finalize
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 00:17:26 +0100] rev 44434
transaction: clarify the logic around pre-finalize/post-finalize I am taking a bit more verbose route, but I find it easier to follow for people who (re)discover the code. (This is a gratuitous cleanup I did while looking at something else.) Differential Revision: https://phab.mercurial-scm.org/D8176
Fri, 28 Feb 2020 00:02:03 +0100 transaction: move constant to upper case
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 00:02:03 +0100] rev 44433
transaction: move constant to upper case These constant are internal to the module and can be safely renamed. Having them upper case help to clarify their "constant" status. (This is a gratuitous cleanup I did while looking at something else.) Differential Revision: https://phab.mercurial-scm.org/D8175
Wed, 26 Feb 2020 22:26:28 +0100 tests: handle In-Reply-To headers for line wrapping
Joerg Sonnenberger <joerg@bec.de> [Wed, 26 Feb 2020 22:26:28 +0100] rev 44432
tests: handle In-Reply-To headers for line wrapping Python 3 tends to insert a newline for both Message-ID and In-Reply-To headers, so unwrap both. Just check the wrapped line format explicitly without regular expression. Differential Revision: https://phab.mercurial-scm.org/D8171
Wed, 26 Feb 2020 10:48:56 -0800 tests: use new, use-case-specific methods from merge module
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 10:48:56 -0800] rev 44431
tests: use new, use-case-specific methods from merge module Differential Revision: https://phab.mercurial-scm.org/D8169
Wed, 26 Feb 2020 10:40:31 -0800 merge: introduce a merge() for that use-case
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 10:40:31 -0800] rev 44430
merge: introduce a merge() for that use-case In the same vein as some earlier patches like f546d2170b0f (merge: introduce a clean_update() for that use-case, 2020-01-15). Differential Revision: https://phab.mercurial-scm.org/D8168
Wed, 26 Feb 2020 11:00:50 -0800 merge: drop redundant mergeforce argument from hg.merge()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 11:00:50 -0800] rev 44429
merge: drop redundant mergeforce argument from hg.merge() The only caller that passed a value for either `force` or `mergeforce` passed the same value for both, so let's simplify the interface by accepting only `force`. Differential Revision: https://phab.mercurial-scm.org/D8167
Wed, 26 Feb 2020 10:54:17 -0800 merge: change default of hg.merge()'s "force" argument from None to False
Martin von Zweigbergk <martinvonz@google.com> [Wed, 26 Feb 2020 10:54:17 -0800] rev 44428
merge: change default of hg.merge()'s "force" argument from None to False The argument is only passed to `mergemode.update()`, and that function treats `None` just like `False`, so `False` seems clearer. Differential Revision: https://phab.mercurial-scm.org/D8166
Thu, 13 Feb 2020 21:14:20 -0800 debugmergestate: make templated
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 21:14:20 -0800] rev 44427
debugmergestate: make templated Our IntelliJ team wants to be able to read the merge state in order to help the user resolve merge conflicts. They had so far been reading file contents from p1() and p2() and their merge base. That is not ideal for several reasons (merge base is not necessarily the "graft base", renames are not handled, commands like `hg update -m` is not handled). It will get especially bad as of my D7827. This patch makes the output s a templated. I haven't bothered to make it complete (e.g. merge driver states are not handled), but it's probably good enough as a start. I've done a web search for "debugmergestate" and I can't find any indication that any tools currently rely on its output. If it turns out that we get bug reports for it once this is released, I won't object to backing this patch out on the stable branch (and then perhaps replace it by a separate command, or put it behind a new flag). The changes in test-backout.t are interesting, in particular this: ``` - other path: foo (node not stored in v1 format) + other path: (node foo) ``` I wonder if that means that we actually read v1 format incorrectly. That seems to be an old format that was switched away from in 2014, so it doesn't matter now anyway. Differential Revision: https://phab.mercurial-scm.org/D8120
Thu, 13 Feb 2020 21:55:38 -0800 tests: add tests of debugmergestate with unresolved/resolved path conflicts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 21:55:38 -0800] rev 44426
tests: add tests of debugmergestate with unresolved/resolved path conflicts I'm about to change `hg debugmergestate` and it broke on these "pu" and "pr" records on my first attempt (D8113), so let's add test coverage. Differential Revision: https://phab.mercurial-scm.org/D8119
Thu, 13 Feb 2020 17:15:08 -0800 mergestate: determine if active without looking for state files on disk
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Feb 2020 17:15:08 -0800] rev 44425
mergestate: determine if active without looking for state files on disk I couldn't think of a reason that we need to check state files on disk to determine if a merge is active. I could imagine them being for there for detecting broken state files that would then be cleaned up by some later command, but we always delete the entire `.hg/merge/` tree, so that doesn't seem to be it. The checks were added in 4e932dc5c113 (resolve: abort when not applicable (BC), 2014-04-18). Perhaps there were needed for that and then made obsolete by 6062593d8b06 (resolve: don't abort resolve -l even when no merge is in progress, 2014-05-23). The reason I want to delete the checks is that I think `ms = mergestate.read(repo); ms.active() and ms.local` should be a valid pattern, but it crashes when the merge state file is an empty file if we consider mere presence of the file as "active". Differential Revision: https://phab.mercurial-scm.org/D8118
Wed, 26 Feb 2020 14:43:02 -0500 phabricator: update the protocol documentation
Matt Harbison <matt_harbison@yahoo.com> [Wed, 26 Feb 2020 14:43:02 -0500] rev 44424
phabricator: update the protocol documentation The `branch` property wasn't added to the `hg:meta` example when it was added to the metadata in d49ab47be8a6. Additionally, `properties` in the Differential Revision dict is a dinctionary, not a list. While here, also alphabetize the responses from Phabricator because that's how it is being printed with `hg debugcallconduit`, and this makes it easier to compare. Differential Revision: https://phab.mercurial-scm.org/D8170
Wed, 26 Feb 2020 10:56:27 -0500 relnotes: move entry to the right spot
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 26 Feb 2020 10:56:27 -0500] rev 44423
relnotes: move entry to the right spot It appears a conflict resolution went wrong. Differential Revision: https://phab.mercurial-scm.org/D8151
Wed, 26 Feb 2020 17:16:25 +0100 revlog-compression: release note entry for update the config to be a list
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 26 Feb 2020 17:16:25 +0100] rev 44422
revlog-compression: release note entry for update the config to be a list I updated the changeset, but forgot to phabsend apparently. Differential Revision: https://phab.mercurial-scm.org/D8165
Tue, 18 Feb 2020 19:11:18 +0100 rust-nodemap: a method for full invalidation
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:18 +0100] rev 44421
rust-nodemap: a method for full invalidation This will be used for exceptional operations, such as a `__delitem__` on the `MixedIndex` with Rust nodemap. In principle, `NodeTree` should also be able to forget an entry in an efficient way, by accepting to insert `Element::None` instead of only `Element::Rev(r)`, but that seems really overkill at this point. We need to support exceptional operations such as `__delitem__`, only for completeness of the revlog index as seen from Python. The Python callers don't seem to even really need it, deciding to drop the nodemap unconditionally at at higher level when calling `hg strip`. Also, `hg strip` is very costly for reasons that are unrelated to nodemap aspects. Differential Revision: https://phab.mercurial-scm.org/D8098
Tue, 18 Feb 2020 19:11:17 +0100 rust-nodemap: accounting for dead blocks
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:17 +0100] rev 44420
rust-nodemap: accounting for dead blocks By the very append-only nature of the `NodeTree`, inserting new blocks has the effect of making some of the older ones useless as they become unreachable. Therefore some automatic housekeeping will need to be provided. This is standard procedure in the word of databases, under names such as "repack" or "vacuum". The new `masked_readonly_blocks()` will provide callers with useful information to decide if the nodetree is ripe for repacking, but all the `NodeTree` can provide is how many blocks have been masked in the currently mutable part. Analysing the readonly part would be way too long to do it for each transaction and defeat the whole purpose of nodemap persistence. Serializing callers (from the Python layer) will get this figure before each extraction and maintain an aggregate counter of unreachable blocks separately. Note: at this point, the most efficient repacking is just to restart afresh with a full rescan. Differential Revision: https://phab.mercurial-scm.org/D8097
Tue, 18 Feb 2020 19:11:17 +0100 rust-nodemap: core implementation for shortest
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:17 +0100] rev 44419
rust-nodemap: core implementation for shortest In this implementation, we just make `lookup()` return also the number of steps that have been needed to come to a conclusion from the nodetree data, and `validate_candidate()` takes care of the special cases related to `NULL_NODE`. This way of doing minimizes code duplication, but it means that the comparatively slower finding of first non zero nybble will run for all calls to `find()` where it is not needed. Still running on the file generated for the mozilla-central repository, it seems indeed that we now get more ofter 320 ns than 310. The odds that this could have a significant impact on real life Mercurial performance are still looking low. Let's wait for actual benchmark runs to see if an optimization is needed here. Differential Revision: https://phab.mercurial-scm.org/D7819
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip