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 44418
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 44417
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 44416
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
Wed, 04 Mar 2020 11:51:13 -0500 Added signature for changeset 6d121acbb82e stable
Augie Fackler <raf@durin42.com> [Wed, 04 Mar 2020 11:51:13 -0500] rev 44415
Added signature for changeset 6d121acbb82e
Wed, 04 Mar 2020 11:51:12 -0500 Added tag 5.3.1 for changeset 6d121acbb82e stable
Augie Fackler <raf@durin42.com> [Wed, 04 Mar 2020 11:51:12 -0500] rev 44414
Added tag 5.3.1 for changeset 6d121acbb82e
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 44413
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 44412
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 tip