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().
Wed, 03 Dec 2014 14:03:20 -0800 merge: make 'keep' message more descriptive
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 14:03:20 -0800] rev 23482
merge: make 'keep' message more descriptive Most merge action messages don't describe the action itself, they describe the reason the action was taken. The only exeption is the 'k' action, for which the message is just "keep" and instead there is a code comment folling it that says "remote unchanged". Let's move that comment into the merge action message.
Thu, 04 Dec 2014 23:08:27 -0500 addremove: restore the relative path printing when files are named
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Dec 2014 23:08:27 -0500] rev 23481
addremove: restore the relative path printing when files are named This fixes the previously mentioned issue with 3778884197f0, and undoes its corresponding test change. The test change demonstrates the correctness when a file is specified (i.e. the glob is required on Windows because relative paths use '\' and absolute paths use '/'). It is admittedly very subtle, but there will be a more robust test in the addremove -S v3 series.
Thu, 04 Dec 2014 23:04:55 -0500 match: introduce uipath() to properly style a file path
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Dec 2014 23:04:55 -0500] rev 23480
match: introduce uipath() to properly style a file path Several methods print files relative to the repo root, unless files are named on the command line, in which case they are printed relative to cwd. Since the check relies on the 'pats' parameter, which needs to be replaced by a matcher when adding subrepo support, this logic gets folded into the matcher to tidy up the callers. Prior to 3778884197f0, this style decision was based off of whether or not the 'pats' list was empty. That change altered the check to test match.anypats() instead, in order to make paths printed consistent when -I/-X is specified. That however, changed the style when a file is given to the command. So now we test the pattern list to get the old behavior for files, as well as test -I/-X to get the consistency for patterns.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip