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)
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip