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.
Thu, 20 Nov 2014 16:27:55 -0800 perf: add a perfloadmarkers command
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 20 Nov 2014 16:27:55 -0800] rev 23485
perf: add a perfloadmarkers command It is used to benchmark the obsstore initialization time.
Wed, 19 Nov 2014 03:38:51 +0100 rebase: move base calculation from rebasenode() to defineparents()
Mads Kiilerich <madski@unity3d.com> [Wed, 19 Nov 2014 03:38:51 +0100] rev 23484
rebase: move base calculation from rebasenode() to defineparents() We want to collect all calculation in one place.
Fri, 05 Dec 2014 10:53:25 -0800 largefiles: remove redundant checks for false modify/delete conflicts
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 10:53:25 -0800] rev 23483
largefiles: remove redundant checks for false modify/delete conflicts In a34a99181f36 (largefiles: don't show largefile/normal prompts if one side is unchanged, 2014-12-01), overridecalculateupdates() started checking for false modify/delete conflicts in large files and their standins. Then, in the very next changeset, 902554884335 (merge: before cd/dc prompt, check that changed side really changed, 2014-12-01), calculateupdates() itself started checking for false modify/delete conflicts in all files. Since "large files and their standins" is a subset of "all files", we can now drop the checks in overridecalculateupdates().
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip