Mon, 20 Nov 2017 21:08:18 -0800 run-tests: organize options into argument groups
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Nov 2017 21:08:18 -0800] rev 35188
run-tests: organize options into argument groups And sort arguments so help output is more legible. There are probably a ton of ways to group things. I tried to picture the test harness as a pipeline and attempted to draw boundaries around stages in that pipeline to create the groupings. Differential Revision: https://phab.mercurial-scm.org/D1475
Mon, 20 Nov 2017 20:41:43 -0800 run-tests: convert to argparse
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Nov 2017 20:41:43 -0800] rev 35187
run-tests: convert to argparse optparse has been deprecated since Python 3.2. Best to get on the new boat before the old one sinks. It looks like argparse formats its usage string differently than optparse. Meh. Differential Revision: https://phab.mercurial-scm.org/D1474
Fri, 01 Dec 2017 15:21:05 -0600 merge with stable
Kevin Bullock <kbullock+mercurial@ringworld.org> [Fri, 01 Dec 2017 15:21:05 -0600] rev 35186
merge with stable
Thu, 16 Nov 2017 03:52:42 +0100 server: introduce a 'experimental.single-head-per-branch' option
Boris Feld <boris.feld@octobus.net> [Thu, 16 Nov 2017 03:52:42 +0100] rev 35185
server: introduce a 'experimental.single-head-per-branch' option When the option is set, the repository will reject any transaction adding multiple heads to the same named branch. For now we reject all scenario with multiple heads. One could imagine handling closed branches differently. We prefer to keep things simple for now. The feature might get extended later. Branch closing is not the best experience Mercurial has to offer anyway.
Thu, 16 Nov 2017 03:52:38 +0100 scmutil: extra utility to display a reasonable amount of nodes
Boris Feld <boris.feld@octobus.net> [Thu, 16 Nov 2017 03:52:38 +0100] rev 35184
scmutil: extra utility to display a reasonable amount of nodes Push have some logic to display a reasonable amount nodes. We extract it to an utility function to make it reusable.
Fri, 06 Oct 2017 04:17:36 +0530 uncommit: unify functions _uncommitdirstate and _unamenddirstate to one
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 06 Oct 2017 04:17:36 +0530] rev 35183
uncommit: unify functions _uncommitdirstate and _unamenddirstate to one The _unamenddirstate() function was inspired by _uncommitdirstate() function as the logic was same but we were unable to use the latter function directly. So previous patch introduced the _unamenddirstate() function and now this patch unifies both the function and we have a _fixdirstate() function. Adding function in previous patch and unifying in a later patch makes the reasoning easier and also leaves the last patch dedicated to what it is meant to be. Differential Revision: https://phab.mercurial-scm.org/D971
Sun, 24 Sep 2017 00:56:52 +0530 unamend: move fb extension unamend to core
Pulkit Goyal <7895pulkit@gmail.com> [Sun, 24 Sep 2017 00:56:52 +0530] rev 35182
unamend: move fb extension unamend to core unamend extension adds an unamend command which undoes the effect of the amend command. This patch moves the unamend command from that extension to uncommit extension and this one does not completely undoes the effect of amend command as it creates a new commit, rather than reviving the old one back. This also adds tests for the same. .. feature:: A new unamend command in uncommit extension which undoes the effect of the amend command by creating a new changeset which was there before amend and moving the changes that were amended to the working directory. Differential Revision: https://phab.mercurial-scm.org/D821
Tue, 28 Nov 2017 13:27:43 -0500 color: respect HGPLAINEXCEPT=color to allow colors while scripting (issue5749)
Augie Fackler <augie@google.com> [Tue, 28 Nov 2017 13:27:43 -0500] rev 35181
color: respect HGPLAINEXCEPT=color to allow colors while scripting (issue5749) I'd also like --color=always on the command-line to override HGPLAIN=1 et al, but that's more work, and this seems like a better fix. We've got a fair number of programs that actually want to automate hg and get colored output to users, so they should set HGPLAINEXCEPT=alias (what we usually recommend), but this has been breaking them because they then lose color. .. feature:: The ``HGPLAINEXCEPT`` environment variable can now include ``color`` to allow automatic output colorization in otherwise automated environments. Differential Revision: https://phab.mercurial-scm.org/D1532
Sun, 26 Nov 2017 11:22:27 +0900 test-ssh: do not actually look up "brokenrepository" by DNS
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Nov 2017 11:22:27 +0900] rev 35180
test-ssh: do not actually look up "brokenrepository" by DNS
Thu, 23 Nov 2017 01:21:10 -0500 largefiles: explicitly set the source and sink types to 'hg' for lfconvert
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 Nov 2017 01:21:10 -0500] rev 35179
largefiles: explicitly set the source and sink types to 'hg' for lfconvert I stumbled into this prior to adding the type indicator on the source and sink, but there's no reason to try to infer the types for this conversion.
Wed, 22 Nov 2017 22:38:50 -0500 lfs: add a repo requirement for this extension when converting to lfs
Matt Harbison <matt_harbison@yahoo.com> [Wed, 22 Nov 2017 22:38:50 -0500] rev 35178
lfs: add a repo requirement for this extension when converting to lfs This covers both the vanilla repo -> lfs repo and largefiles -> lfs conversions. The largefiles extension adds the requirement directly, because it has a dedicated command to convert. Using the convert extension is better, because it supports more features. I'd like ideas about how to ensure that converting away from lfs works on all files. (See comments in test-lfs.t)
Sun, 26 Nov 2017 14:59:39 -0500 convert: allow the sink object to be wrapped when the extension isn't loaded
Matt Harbison <matt_harbison@yahoo.com> [Sun, 26 Nov 2017 14:59:39 -0500] rev 35177
convert: allow the sink object to be wrapped when the extension isn't loaded The next patch will wrap the conversion code, in order to write out a requirement for 'lfs' when appropriate. Wrapping convcmd.convertsink() in an afterloaded callback works fine when the convert extension is enabled by the user. The problem here is that lfconvert uses the convert extension, whether or not it was formally enabled by the user. My first attempt was to have lfs install an afterloaded callback that would wrap the convert sink if convert was loaded, or wrap lfconvert if it wasn't. Then the lfconvert override could install an afterloaded callback to try wrapping the convert sink again, before calling the original lfconvert. But that breaks down if largefiles can't load the convert extension on the fly. [1] Further, some tests were failing with an error indicating that the size of the afterloaded list changed while iterating it. Yuya mentioned that maybe some bits of convert could be moved into core, but I'm not sure where to draw that line. The convertsink() method depends on the list of sinks, which in turn depends on the sink classes. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/108038.html
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip