Grouping all evolution related-config under the experimental.evolution
namespace would helps the future migration outside [experimental].
Differential Revision: https://phab.mercurial-scm.org/D1155
Depends on D931.
This patch introduces functions and a config option that will allow a user
to halt the merge if there are failures during a file merge. These functions
will be used in the next patch.
Differential Revision: https://phab.mercurial-scm.org/D932
The new 'txnclose-phase' hook expose the phase movement information stored in
'tr.changes['phases]'. To provide a simple and straightforward hook API to the
users, we introduce a new hook called for each revision affected. Since a
transaction can affect the phase of multiple changesets, updating the existing
'txnclose' hook to expose that information would be more complex. The data for
all moves will not fit in environment variables and iterations over each move
would be cumbersome. So the introduction of a new dedicated hook is
preferred in this changesets.
This does not exclude the addition of the full phase movement information to
the existing 'txnclose' in the future to help write more complex hooks.
The new 'txnclose-bookmark' hook expose the bookmark movement information
stored in 'tr.changes['bookmarks]'. To provide a simple and straightforward
hook API to the users, we introduce a new hook called for each bookmark
touched. Since a transaction can affect multiple bookmarks, updating the
existing 'txnclose' hook to expose that information would be more complex. The
data for all moves might not fit in environment variables and iterations over
each move would be cumbersome. So the introduction of a new dedicated hook is
preferred in this changeset.
This does not exclude the addition to the full bookmark information to the
existing 'txnclose' in the future to help write more complex hooks.
.. feature::
New `commands.update.check` feature to adjust constraints on when
`hg update` will allow updates with a dirty working copy.
also
.. bc::
The `experimental.updatecheck` name for the new `commands.update.check`
feature is now deprecated, and will be removed after this release.
Differential Revision: https://phab.mercurial-scm.org/D1070
--uncompressed isn't a very good name and its description in the
help documentation isn't very useful. We refer to this concept as
"stream clones" in a number of places. I think it makes sense to
change the user-facing argument to use the mode --stream. So this
commit does that.
We keep --uncompressed around for backwards compatibility.
While we're here, we overhaul the help docs for streaming clones
to be somewhat useful.
All tests have been updated to reflect the new preferred --stream
argument. A test for backwards compatibility of --uncompressed has
been added.
.. bc::
`hg clone --stream` should now be used instead of --uncompressed.
--uncompressed is marked as deprecated and is an alias for --stream.
There is no schedule for elimination of --uncompressed.
Differential Revision: https://phab.mercurial-scm.org/D864
This patch limits the estimate time interval to roughly the last minute
(configurable by `estimateinterval`) to be more practical. See the test
change for why this is better.
.. feature:: Estimated time is more accurate with non-linear progress
Differential Revision: https://phab.mercurial-scm.org/D820
When ui.origbackuppath is set, .orig files are stored outside of the working
copy, however they still have a .orig suffix appended to them. This can cause
unexpected conflicts, particularly when tracked files or directories have .orig
at the end.
This change removes the .orig suffix from files stored in an out-of-tree
origbackuppath.
Test Plan:
Update and run unit tests.
Differential Revision: https://phab.mercurial-scm.org/D679
Add an option that only ignores whitespaces at EOL. The name of the option is
the same as Git.
.. feature::
Added `--ignore-space-at-eol` diff option to ignore whitespace differences
at line endings.
Differential Revision: https://phab.mercurial-scm.org/D422
The presence of a sparse checkout can confuse legacy clients or
clients without sparse enabled for reasons that should be obvious.
This commit introduces a new repository requirement that tracks
whether sparse is enabled. The requirement is added when a sparse
config is activated and removed when the sparse config is reset.
The localrepository constructor has been taught to not open repos
with this requirement unless the sparse feature is enabled. It yields
a more actionable error message than what you would get if the
lockout were handled strictly at the requirements verification phase.
Old clients that aren't sparse aware will see the generic
"repository requires features unknown to this Mercurial" error,
however.
The new requirement has "exp" in its name to reflect the
experimental nature of sparse. There's a chance that the eventual
non-experimental feature won't change significantly and we could
have squatted on the "sparse" requirement without ill effect. If
that happens, we can teach new clients to still recognize the old
name. But I suspect we'll sneak in some BC and we'll want a new
requirement to convey new meaning.
Differential Revision: https://phab.mercurial-scm.org/D110
"merge-tools" help topic has described that the merge of the file
fails if no tool is found to merge binary or symlink, since
9da9bced2226 (or Mercurial 1.7), which based on (already removed)
MergeProgram wiki page.
But even at that revision, and of course now, merge of the file
doesn't fail automatically for binary/symlink. ":prompt" (or
equivalent logic) is used, if there is no appropriate tool
configuration for binary/symlink.
As an aside, I'm having trouble parsing the help text meaning for HG when it is
unset or empty. How can it be the frozen name or searched if it is empty?
This may be too subtle of a change to get the point across, but when I first
read the original text, I thought maybe the pager would only be invoked if
writing more than a screenful. The distinction between this and a pager that
simply exits after printing less than a screenful is important on Windows, given
the inability of `more` to color output.
Even though I figured this out a few weeks ago, I was initially puzzled where
the color went when I upgraded to 4.2 on a different Windows machine. Let's
point users reading the help into the right direction.
I wonder if we should be even more explicit about cmd.exe/MSYS/pager/color
interplay, but at least all of the breadcrumbs are here (I think).
This aligns with what we do for color (see cea7a760c58d). Pager is a central
enough notion that having the master config in the [ui] section makes senses. It
will helps with consistency, discoverability. It will also help having a simple
and clear example hgrc mentioning pager.
The previous form of the option had never been released in a non-rc version but
we keep it around for convenience. If both are set, 'ui.pager' take priority.
Previously, 'ui.color=yes' meant "always show color", While
"ui.color=auto" meant "use color automatically when it appears
sensible".
This feels problematic to some people because if an administrator has
disabled color with "ui.color=off", and a user turn it back on using
"color=on", it will get surprised (because it breaks their output when
redirected to a file.) This patch changes ui.color=true to only move the
default value of --color from "never" to "auto".
I'm not really in favor of this changes as I suspect the above case will
be pretty rare and I would rather keep the logic simpler. However, I'm
providing this patch to help the 4.2 release in the case were others
decide to make this changes.
Users that want to force colors without specifying --color on the
command line can use the 'ui.formatted' config knob, which had to be
enabled in a handful of tests for this patch.
Nice summary table (credit: Augie Fackler)
That is, before this patch:
+--------------------+--------------------+--------------------+
| | not a tty | a tty |
| | --color not set | --color not set |
| | | |
+--------------------+--------------------+--------------------+
| [ui] | | |
| color (not set) | no color | no color |
| | | |
+--------------------+--------------------+--------------------+
| [ui] | | |
| color = auto | no color | color |
| | | |
+--------------------+--------------------+--------------------+
| [ui] | | |
| color = yes | *color* | color |
| | | |
+--------------------+--------------------+--------------------+
| [ui] | | |
| color = no | no color | no color |
| | | |
+--------------------+--------------------+--------------------+
(if --color is specified, it always clobbers the setting in [ui])
and after this patch:
+--------------------+--------------------+--------------------+
| | not a tty | a tty |
| | --color not set | --color not set |
| | | |
+--------------------+--------------------+--------------------+
| [ui] | | |
| color (not set) | no color | no color |
| | | |
+--------------------+--------------------+--------------------+
| [ui] | | |
| color = auto | no color | color |
| | | |
+--------------------+--------------------+--------------------+
| [ui] | | |
| color = yes | *no color* | color |
| | | |
+--------------------+--------------------+--------------------+
| [ui] | | |
| color = no | no color | no color |
| | | |
+--------------------+--------------------+--------------------+
(if --color is specified, it always clobbers the setting in [ui])
Unlike a mapfile whose template is looked up by spec -> mapfile -> topic,
[templates] section is global. We use :sub-section syntax to define parts
per template.
We point out at the help of the config option for user who wants to learn more
about the possible config value.
The suggested command returns some other extra (color related) results, but this
is bug to fix outside of the freeze.
The --color option is described to accept "boolean, always, auto,
never, or debug". Let's use a similar description for ui.color. Also
fix the formatting to use double quotes as we seem to use for about
half the values in config.txt (the other half uses double
backticks). Also use uppercase Boolean for consistency within the
file.
There are some paragraphs, which aren't rendered in online help as
expected because of indentation and literal blocking issues.
- hgext/rebase.py
- paragraph before example code ends with ":", which treats
subsequent indented paragraphs as normal block
=> replace ":" with "::" to treat subsequent paragraphs as literal block
- help/pager.txt
- paragraph before a list of --pager option values ends with "::",
which treats subsequent indented paragraphs as literal block
=> replace "::" with ":" to treat subsequent paragraphs as normal block
- the second line of explanation for no/off --pager option value is
indented incorrectly (this also causes failure of "make" in doc)
=> indent correctly
- help/revisions.txt
- explanation following example code of "[revsetalias]" section
isn't suitable for literal block
=> un-indent explanation paragraph to treat it as normal block
- indentation of "For example" before example of tag() revset
predicate matching is meaningless
- descriptive text for tag() revset predicate matching isn't
suitable for literal block
=> un-indent concatenated two paragraphs to treat them as normal block
I've been using `hg serve --web-conf ...` with a simple '/=projects/**' [paths]
configuration for awhile without issue. Let's ditch the need for the manual
configuration in this case, and limit the repos served to the actual subrepos.
This doesn't attempt to handle the case where a new subrepo appears while the
server is running. That could probably be handled with a hook if somebody wants
it. But it's such a rare case, it probably doesn't matter for the temporary
serves.
The main repo is served at '/', just like a repository without subrepos. I'm
not sure why the duplicate 'adding ...' lines appear on Linux. They don't
appear on Windows (see 3f4ff1bdf101), so they are optional.
Subrepositories that are configured with '../path' or absolute paths are not
cloneable from the server. (They aren't cloneable locally either, unless they
also exist at their configured source, perhaps via the share extension.) They
are still served, so that they can be browsed, or cloned individually. If we
care about that cloning someday, we can probably just add the extra entries to
the webconf dictionary. Even if the entries use '../' to escape the root, only
the related subrepositories would end up in the dictionary.
Mercurial can't currently send cookies as part of HTTP requests.
Some authentication systems use cookies. So, it seems like adding
support for sending cookies seems like a useful feature.
This patch implements support for reading cookies from a file
and automatically sending them as part of the request. We rely
on the "cookiejar" Python module to do the heavy lifting of
parsing cookies files. We currently only support the Mozilla
(really Netscape-era) cookie format. There is another format
supported by cookielib and we may want to consider using that,
especially since the Netscape cookie parser can't parse ports.
It wasn't immediately obvious to me what the format of the other
parser is, so I didn't know how to test it. I /think/ it might
be literal "Cookie" header values, but I'm not sure. If it is
more robust than the Netscape format, we may want to just
support it.
We move the feature to a proper configuration and document it. The config goes
in the 'server' section because it feels like something the server owner would
want to decide. We pick and open field because it seems likely that other
checking levels will emerge in the future. (eg: server like the mozilla-try
server will likely wants a "none" value)
The option name contains 'push' since this affects 'push' only. The option value
'check-related' is preferred over one explicitly containing 'allow' or 'deny'
because the client still have a strong decision power here. Here, the server is
just advising the client on the check mode to use.
Since a map file has another level to select a template (spec -> mapfile
-> topic), this isn't exactly the same as how a map file works. But I believe
most users would expect the new behavior.
A literal template is stored as an unnamed template so that it will never
conflict with the templates defined in [templates] section.
We've been talking for years about a one-stop config knob to opt in to
better behavior. There have been a lot of ideas thrown around, but
they all seem to be too complicated to get anyone to actually do the
work.. As such, this patch is the stupidest thing that can possibly
work in the name of getting a good feature to users.
Right now it's just three config settings that I think are generally
uncontroversial, but I expect to add more soon. That will likely
include adding new config knobs for the express purpose of adding them
to tweakdefaults.
statprof.display_hotpath() accepts a "limit" function to choose the
minimum threshold for samples to display. The default is 0.05, which
means you don't need individual items contributing less than 5%.
I had a need to adjust this threshold. We already have a config
option for it. So let's reuse it.
check-config.py doesn't like having multiple defaults for the
ui.configwith() calls. The behavior is obviously correct. I'm
not sure if it is worth teaching check-config.py how to ignore
this. So I've just accepted the new output.
