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.

--HG--
extra : rebase_source : 007c459ee2956316216fdf3b6b886aa5cdf21cd9
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.

--HG--
extra : rebase_source : e89acf3e8c30e6aa9236e1fc021709344cc9f32f
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.
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().
rebase: move base calculation from rebasenode() to defineparents()

We want to collect all calculation in one place.

--HG--
extra : amend_source : d5cc4db212348725dda01b322232cf794dfb3782
perf: add a perfloadmarkers command

It is used to benchmark the obsstore initialization time.
patchbomb: extract 'getoutgoing' closure into its own function

This continues my crusade against closure complication.

--HG--
extra : rebase_source : 7f2cf2cb649102ebab3c572a4ed5daa0de934ff8
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.
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.

--HG--
extra : rebase_source : 0887c7e64534ef5180292aa9e8332cf1796ec2cc
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.

--HG--
extra : rebase_source : fc9a55f66dd0a4fb7e349cf9b7a9b77d594b3c20
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.

--HG--
extra : rebase_source : 682beda8418ac5807ed50b42b5c6644d731b1f05
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.

--HG--
extra : rebase_source : e81ed21838e28a964fa4cc7e4c9991a16df07761