Thu, 04 Dec 2014 05:43:40 -0800 util: add a 'nogc' decorator to disable the garbage collection
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 05:43:40 -0800] rev 23495
util: add a 'nogc' decorator to disable the garbage collection Garbage collection behave pathologically when creating a lot of containers. As we do that more than once it become sensible to have a decorator for it. See inline documentation for details.
Fri, 05 Dec 2014 22:58:02 -0500 generate-working-copy-states: open() in binary mode when writing content
Matt Harbison <matt_harbison@yahoo.com> [Fri, 05 Dec 2014 22:58:02 -0500] rev 23494
generate-working-copy-states: open() in binary mode when writing content This avoids changes to the hashes on Windows in test-merge-force.t like so: @@ -594,12 +594,12 @@ content2 M missing_content2_content3_content4-tracked - <<<<<<< local: 443153eb5b88 - test: local\r (esc) - content4 - ||||||| base - ======= - content2 - >>>>>>> other: 9b2ccd328a08 - test: remote\r (esc) + <<<<<<< local: 0447570f1af6 - test: local + content4 + ||||||| base + ======= + content2 + >>>>>>> other: 85100b8c675b - test: remote missing_content2_content3_content4-tracked.orig: content4
Fri, 05 Dec 2014 16:45:52 -0800 largefiles: don't use 'r' action for standin that doesn't exist
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:45:52 -0800] rev 23493
largefiles: don't use 'r' action for standin that doesn't exist When merging and the remote has turned a normal file into a largefile and the user chooses to keep the local largefile, we use the 'r' action for the remote largefile standin. This is wrong, since that file does not exist in the parent of the working copy. Use 'k', which does nothing but debug logging, instead.
Fri, 05 Dec 2014 16:51:37 -0800 largefiles: don't use 'r' action for normal file that doesn't exist
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:51:37 -0800] rev 23492
largefiles: don't use 'r' action for normal file that doesn't exist When merging and the remote has turned a largefile into a normal file and the user chooses to keep the local largefile, we use the 'r' action for the remote normal file. This is wrong, since that file does not exist in the parent of the working copy. Use 'k', which does nothing but debug logging, instead.
Tue, 02 Dec 2014 12:23:12 -0800 rebase: handle revtodo as a special value when storing/restoring state
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 12:23:12 -0800] rev 23491
rebase: handle revtodo as a special value when storing/restoring state Revtodo happens to share its value with nullrev, but this is an implementation details, so we move away from it. After this changeset one can successfully change the values for all the constants and the tests still pass, but doing so would require more refactoring if we want to avoid breaking backward compatibility on the state file.
Tue, 02 Dec 2014 09:46:20 -0800 rebase: add a 'revtodo' constant
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 09:46:20 -0800] rev 23490
rebase: add a 'revtodo' constant The state mapping is using '-1' to mark revisions that have not been rebased yet. We introduce and use a constant for that purpose. This will help emphasize the fact the value means something other than nullrev.
Thu, 04 Dec 2014 07:03:02 -0800 rebase: use '>= 0' to know is a revision was rebased
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 07:03:02 -0800] rev 23489
rebase: use '>= 0' to know is a revision was rebased The fact that the state for "not yet rebased" is -1 is an implementation details. So we change the comparisons to some semantically more correct.
Tue, 02 Dec 2014 17:35:21 -0800 patchbomb: introduce a 'patchbomb.confirm' option
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 17:35:21 -0800] rev 23488
patchbomb: introduce a 'patchbomb.confirm' option When set to true, this option will make patchbomb always ask for confirmation before sending the email. Confirmation is a powerful way to prevent stupid mistakes when the sending patches. This should let me get rid of my global alias adding --confirm to hg email. I know that some people may get bitten when moving from a machine with confirm configured to a machine where it is not, but I think it is worth the risk.
Tue, 02 Dec 2014 17:24:52 -0800 patchbomb: add a 'patchbomb.intro' option
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 17:24:52 -0800] rev 23487
patchbomb: add a 'patchbomb.intro' option This option allows the user to control the default behavior for including an introduction message. This avoids having to tirelessly skip the intro for people contributing to Mercurial. The three possibles values are: - always, - auto (default, current behavior), - never. I was thinking of ("true", "false", "") (empty value being auto) but I ruled it out as too confusing. This new config option reuses the pre-existing 'patchbomb' section.
Tue, 02 Dec 2014 16:51:32 -0800 patchbomb: extract 'getoutgoing' closure into its own function
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 16:51:32 -0800] rev 23486
patchbomb: extract 'getoutgoing' closure into its own function This continues my crusade against closure complication.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip