Sat, 09 May 2020 20:25:07 +0200 manifest-cache: ignore IOError while writing stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 09 May 2020 20:25:07 +0200] rev 44817
manifest-cache: ignore IOError while writing If the wcache directory is non writable for some reason (eg: belong to root). Trying to write to it currently crash Mercurial. Instead we ignore the error and skip writing that cache. We should probably improve the user experience of multiple users interacting with the same repository. However this is not an adventure for stable. Differential Revision: https://phab.mercurial-scm.org/D8512
Wed, 06 May 2020 11:40:17 -0700 copy: give better error message when no source paths found with --at-rev stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:40:17 -0700] rev 44816
copy: give better error message when no source paths found with --at-rev The new error message matches what we show when marking copies in the working copy. Differential Revision: https://phab.mercurial-scm.org/D8496
Wed, 06 May 2020 11:41:37 -0700 tests: show poor error message for `hg cp -A --at-rev . non-existent dst` stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:41:37 -0700] rev 44815
tests: show poor error message for `hg cp -A --at-rev . non-existent dst` Differential Revision: https://phab.mercurial-scm.org/D8495
Wed, 06 May 2020 10:33:56 -0700 copy: to find copy source, walk parent of revision we're marking copies in stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 10:33:56 -0700] rev 44814
copy: to find copy source, walk parent of revision we're marking copies in As shown in the previous patch, `hg cp --after --at-rev . src dst` fails if `src` is not in `.`. It seems obvious that you should always walk the *parent* of the revision you're marking copies in, but that's not how it was done for the working copy, and I didn't think to change it when marking copies in a non-working-copy commit. This patch fixes that by walking the parent commit instead, but only if we're marking copies for a non-working-copy commit. We need to leave the working-copy code unchanged because it depends on the weird behavior of `workingctx.walk()`. With these changes, there's very little overlap between the working-copy version and the non-working-copy version of `walkpats()`, but I've refrained from cleaning that up on the stable branch. Differential Revision: https://phab.mercurial-scm.org/D8494
Wed, 06 May 2020 11:41:01 -0700 tests: show that `hg cp -A --at-rev .` doesn't work for renames stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:41:01 -0700] rev 44813
tests: show that `hg cp -A --at-rev .` doesn't work for renames I clearly forgot to implement (and test) support for marking of renames when I added support for marking of copies :( Differential Revision: https://phab.mercurial-scm.org/D8493
Fri, 08 May 2020 01:19:48 +0200 formatting: add missing newline stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 08 May 2020 01:19:48 +0200] rev 44812
formatting: add missing newline Differential Revision: https://phab.mercurial-scm.org/D8509
Mon, 27 Apr 2020 01:39:22 +0200 fastexport: downgrade message about already exported changesets to debug stable
Joerg Sonnenberger <joerg@bec.de> [Mon, 27 Apr 2020 01:39:22 +0200] rev 44811
fastexport: downgrade message about already exported changesets to debug The old warning level is just too noisy for incremental processing. Differential Revision: https://phab.mercurial-scm.org/D8487
Mon, 11 May 2020 09:07:31 -0700 revisions: parse "x123" as "nodeid starting with 123" without prefixhexnode
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 May 2020 09:07:31 -0700] rev 44810
revisions: parse "x123" as "nodeid starting with 123" without prefixhexnode `experimental.revisions.prefixhexnode` makes it so the template function `shortest()` uses an "x" prefix to disambiguate between short nodeids and revnums. That config has so far also been used for enabling parsing of "x123" unambiguously as a nodeid. That makes it a little annoying for people who have prefixhexnode=yes to share such nodeids with people who have prefixhexnode=no ("x123" will be considered invalid for them). There seems to be little harm in allowing that parsing for everyone. We still let e.g. bookmark names like "x123" take precedence over the nodeid, so that's not a concern. The only thing I can think of is that people get used to the "x" prefix being valid, making it impossible for us to change to a different prefix if we wanted to do that when graduating the feature. Differential Revision: https://phab.mercurial-scm.org/D8514
Fri, 08 May 2020 08:55:35 -0700 status: use cmdutil.check_at_most_one_arg() for checking --rev/--change
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 May 2020 08:55:35 -0700] rev 44809
status: use cmdutil.check_at_most_one_arg() for checking --rev/--change There are apparently no tests for this either. Differential Revision: https://phab.mercurial-scm.org/D8511
Fri, 08 May 2020 08:50:47 -0700 diff: use cmdutil.check_at_most_one_arg() for checking --rev/--change
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 May 2020 08:50:47 -0700] rev 44808
diff: use cmdutil.check_at_most_one_arg() for checking --rev/--change The same check was done in extdiff as well, so I fixed that too. There are apparently no tests for this. Differential Revision: https://phab.mercurial-scm.org/D8510
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip