We want to issue a warning and abort comparing bookmarks if remote doesn't
support it. Otherwise hg out -B will list you outgoing bookmarks that cannot
be pushed to the remote repository using hg push -B.
hg bookmark -r ancestorrev X will not mark X as the current bookmark anymore.
If you want to point a bookmark to a ancestor rev you will use hg update to
move to it. This will set the current bookmark.
In testing of my recent addition of a debugignore command, some of my MacHg
users uncovered the exceptional case that if there is no ignore patterns of any
kind then a traceback occurred. Catch and fix this case.
Add missing calls to close() to many places where files are
opened. Relying on reference counting to catch them soon-ish is not
portable and fails in environments with a proper GC, such as PyPy.
For GUI clients its sometimes important to know which files will be ignored and
which files will be important. This allows the GUI client to skipping redoing a
'hg status' when the files are ignored but have changed. (For instance, a
typical case is that the "build" directory inside some project is ignored but
files in it frequently change.)
Filenames starting with a dot (.hg and .hgignore) confuse man when
creating the ps documentation with "man -t hg >hg.ps" if they are not
enclosed in back quotes.
The help for backout explains:
The backout command merges the reverse effect of the reverted
changeset into the working directory.
Unfortunately, that does not make it obvious to a newcomer what the
backout command does. Since it performs a 3-way merge, what is the
common ancestor? Will the result be automatically committed? What is
this reverted changeset --- is it the rev passed with -r on the
command line or its inverse?
So try to clarify the description, avoiding jargon and being
explicit about what happens from the user's perspective.
Thanks to Gilles Moris, Steve Borho, Kevin Bullock, and timeless for
help.
If --insecure specified, it behaves in the same way as no web.cacerts
configured.
Also shows hint for --insecure option when _verifycert() failed. But currently
the hint isn't displayed on SSLError, because it needs a certain level of
changes.
Since it's usually only desirable to make tag commits on top of branch
heads, abort if the working dir parent is not a branch head. -f/--force
may be passed to commit at a non-head anyway.
Does not abort if working dir parent is a named branch head but not a
topological head.
This patch corrects the check for tagging on an uncommitted merge. We
should never commit a new tag changeset on an uncommitted merge, whether
or not --rev is specified. It also changes the error message from:
abort: cannot partially commit a merge (do not specify files or patterns)
to the much more accurate (and terse):
abort: uncommitted merge
Local tags are ok.
Invalid extensions in hgext/ could in some cases cause a crash when searching
for unknown commands in disabled extensions.
With this change we issue a warning if extracting commands from the extensions
fails. Traceback is available on request.
Reported on https://bugzilla.redhat.com/show_bug.cgi?id=663183 with forest.py.
Previously, branch names were ideally manipulated as UTF-8 strings,
because they were stored as UTF-8 in the dirstate and the changelog
and could not be safely converted to the local encoding and back.
However, only about 80% of branch name code was actually using the
right encoding conventions. This patch uses the localstr addition to
allow working on branch names as local strings, which simplifies
handling so that the previously incorrect code becomes correct.
ui.forcemerge is set before calling into merge or resolve commands, then unset
to prevent ui pollution for further operations.
ui.forcemerge takes precedence over HGMERGE, but mimics HGMERGE behavior if the
given --tool is not found by the merge-tools machinery. This makes it possible
to do: hg resolve --tool="python mymerge.py" FILE
With this approach, HGMERGE and ui.merge are not harmed by --tool
HGMERGE has different semantics than ui.merge. HGMERGE should hold the name
on an executable in your path, or an absolute tool path. As such, it's not
safe to simply copy the user's specified --tool value into HGMERGE. Instead,
we disable HGMERGE by setting it to an empty string.
This changes backouts changeset to retain linear history, .e. it is committed
as a child of the working directory parent, not the reverted changeset
parent.
The default behavior was previously to just commit a reverted change as a
child of the backed out changeset - thus creating a new head. Most of
the time, you would use the --merge option, as it does not make sense to
keep this dangling head as is.
The previous behavior could be obtained by using 'hg update --clean .' after a
'hg backout --merge'.
The --merge option itself is not affected by this change. There is also
still an autocommit of the backout if a merge is not needed, i.e. in case
the backout is the parent of the working directory.
Previously we had (pwd = parent of the working directory):
pwd older
backout auto merge
backout --merge auto commit
With the new linear approach:
pwd older
backout auto commit
backout --merge auto commit
auto: commit done by the backout command
merge: backout also already committed but explicit merge and commit needed
commit: user need to commit the update/merge
Before this change, "hg help heads" said
hg heads [-ac] [-r REV] [REV]...
[...]
If STARTREV is specified, only those heads that are descendants
of STARTREV will be displayed.
[...]
-r --rev REV show only heads which are descendants of REV
[...]
which made little sense since there are two things called REV in the
synopsis and nothing called STARTREV.
A little digging reveals that the "[-r REV]" part of the synopsis was
introduced in 3acdabb0ef1d, changed to "[-r STARTREV]" in
68df96e9e749, and then changed back to "[-r REV]" in 5c78ba00bf0c.
The last change seems to be based on a patch[1] on our mailinglist
that actually *inserted* STARTREV again in the help for the command
line option itself. For some reason, the patch was changed to remove
STARTREV from the synopsis.
This change finally makes the help consistent by putting STARTREV back
into the help in all places where it is needed:
hg heads [-ac] [-r STARTREV] [REV]...
[...]
If STARTREV is specified, only those heads that are descendants
of STARTREV will be displayed.
[...]
-r --rev STARTREV show only heads which are descendants of STARTREV
[...]
This was not possible until 7ba070acb8f7, which introduced the
possibility of naming the meta variables for each option.
[1]: http://mercurial.markmail.org/message/qgc55gd4fam4ogvz
Most commands expands configured paths when repositories are specified, just as
the urls help says. Clone also expands the destination path. Clone is morally
equivalent to init + push/pull, so init should also expand the destination path
- and that is what this patch makes it do.
There is no really good usecases for this and in most cases it doesn't matter,
but consistency is nice, and otherwise we would have to document the exception.
f02da4369319 assumed that walkchangerevs called prep with all relevant matched
filenames, but actually it only contains the names of files changed in the
relevant changeset. That meant that log diff/stat of merges missed the diff for
files only changed in the other branch.
This is a minimal fix for making sure we only use fns when we are following and
thus will have problems with merges anyway ...
As with push, the optional destination path is ignored for the
subrepositories, i.e., they are always compared with their default
push path. Fixing this is Issue1852.
This removes the warn() function in favor of issuing warnings directly
for each kind of file that Mercurial won't remove.
This also uses three separate translatable strings instead of using
string formatting to build the message. This should make it easier to
localize.
If a repository is accesible, first treat the filename as a working copy file
and try to open its filelog. Fallback to opening the file directly as a
revlog, as before.
If a repository is accesible, first treat the filename as a working copy file
and try to open its filelog. Fallback to opening the file directly as a
revlog, as before.
Currently, a number of commands and help topics mention the user hgrc
file in different ways. Among these are following:
1. .hgrc - "please specify your commit editor/username in your .hgrc
file", bookmarks, color, hgk, pager, hg help environment
2. $HOME/.hgrc - hg help paths, hgrc(5), hg(1)
3. ~/.hgrc - hgrc(5)
In addition to being inconsistent, none of these make sense on
Windows. This patch replaces the above with a more general term of
"[your] configuration file".
This adds util.getport(port) which tries to parse port as an int, and
failing that, looks it up using socket.getservbyname(). Thus, the
following will work:
[smtp]
port = submission
[web]
port = http
This does not apply to ports in URLs used in clone, pull, etc.
This commit updates the branches command to use ui.label for the branch names
and the changeset. This implementation allows assigning colors to the four
states of a branch: active, closed, current and inactive. While you can
configure color for the four states, only current and closed have default colors
of green and black bold respectively.
If you want to programatically perform a revert right now you need to
include a date=False parameter due to the use of opt["date"] instead
of opt.get("date").
When addbranchrevs extends revs, it adds changeset hashes, and not node ids.
Which means that we have to lookup for revisions _after_ the addbranchrevs
call, instead of before.
By renaming before reverting the content of the file we ensure that we handle
and break hardlinks properly.
Handling of other hardlinks to .orig is somebody elses problem.
Branches can have multiple heads, so it doesn't make sense to speak of "the
head of the current branch". What update really does is try to update to the
*tip* of the current branch.
Some encoding and language combinations (e.g.: UTF-8 and Japanese)
cause encoding characters into sequence of bytes more than column
width of them.
So, encoding.colwidth() should be applied instread of len() on i18n
strings.
In addition to it, formatting by '%*s'/'%-*s' also uses "number of
bytes" to calculate space padding size, and should be fixed, too.
This patch adds git-style "shell aliases" to Mercurial.
Any alias with a definition beginning with a '!' will be treated as a shell
alias. For example:
[alias]
echo = !echo
qempty = !hg qrefresh -X "`hg root`" ; echo Emptied patch "`hg qtop`"
$ hg echo foo
foo
$ hg qempty
Emptied patch foo
$
When commiting, a check is made to see if one of the parents is a
closed head. However this did not check that the branch of the commit
is the same as the closed head, so one could get a warning message on
the sequence
hg commit --close-branch
hg branch new-branch
hg commit
or when merging in a closed head.
In commands.log a displayer was initialized from
cmdutil.show_changeset() with the initial matchfn (which designates
the specified files which only is correct in the highest revision in
the range). prep() is handed the correct list of files, but
displayer.show() didn't use that list but keept using the original
matchfn.
The matchfn argument to cmdutil.show_changeset() wasn't specified in
other places and is only used in .show(), so now we give the matchfn
as an optional parameter to .show().
We do however still have to detect --patch and --stat from opts in
show_changeset() and let it imply a matchall, but that can now be
overruled with the new .show() matchfn parameter.
Currently, callers of addchangegroup first acquire the repository
lock, usually to check that an unbundle request isn't racing. This
means that changegroup hook actions that might write to a repo get
stuck waiting for a lock. Here, we add a new optional lock parameter
and update all the callers. Post-1.6 we may make it non-optional.
Currently merge just prints abort-like messages to stderr and then
exits with a misleading status 0 (cleverly disguised as "False").
With this change it raises Abort, just like every other fatal error.
Useful in tests to quickly build a complex DAG in an empty repo.
Handles local tags and named branches.
Options to, at each rev,
- create a new file,
- overwrite the same file,
- append to the same file,
- write to a specific line in a mergeable file.
Can run shell commands during DAG buildup.
Mainly useful for reusing DAGs somewhere else, for example for attaching
them to a bug report, or for importing them into other environments
(like my test environment for incoming/outgoing discovery).
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.
To avoid recurrent fixes for the display of this message, a summary table with
all case combinations has been added to the code.
Basically, there is two condition for the message to be printed:
* this is not an initial (named branch or topo) root
* none of the parents are in the current branch heads
Some implementations of ui.label() (HTML versions in particular) must escape
the provided text and then markup the text with their tags. When this marked
up text is then passed to ui.write(), we must label the text as 'ui.labeled'
so the implementation knows not to escape it a second time (exposing the initial
markup).
This required the addition of a 'ui.plain' label for text that is purposefully
not marked up.
I was a little pedantic here, passing even ' ' strings to ui.label() when it
would be included with other labeled text in a ui.write() call. But it seemed
appropriate to lean to the side of caution.
Mercurial has problem around text wrapping/filling in MBCS encoding
environment, because standard 'textwrap' module of Python can not
treat it correctly. It splits byte sequence for one character into two
lines.
According to unicode specification, "east asian width" classifies
characters into:
W(ide), N(arrow), F(ull-width), H(alf-width), A(mbiguous)
W/N/F/H can be always recognized as 2/1/2/1 bytes in byte sequence,
but 'A' can not. Size of 'A' depends on language in which it is used.
Unicode specification says:
If the context(= language) cannot be established reliably they
should be treated as narrow characters by default
but many of class 'A' characters are full-width, at least, in Japanese
environment.
So, this patch treats class 'A' characters as full-width always for
safety wrapping.
This patch focuses only on MBCS safe-ness, not on writing/printing
rule strict wrapping for each languages
MBCS sensitive textwrap class is originally implemented
by ITO Nobuaki <daydream.trippers@gmail.com>.
Compare this to --force which allows anything to be pushed. With --new-branch,
only changesets to named branches not present on the and changesets not
introducing additional heads on existing branches are allowed.
Developed by
Henrik Stuart <henrik.stuart@edlund.dk>
Sune Foldager <cryo@cyanite.org>
This is in preparation for generaldelta, where the revlog entry base field is
reinterpreted as the deltaparent. For that reason we also rename the base
function to chainbase.
Without generaldelta, performance is unaffected, but generaldelta will suffer
from this in _addrevision, since delta chains will be walked repeatedly.
A cache has been added to eliminate this problem completely.
discovery.findoutgoing used to be a useful hook for extensions like
hgsubversion. This patch reintroduces this version of findcommonincoming
which is meant to be used when computing outgoing changesets.
The Mercurial 1.9 release is moving a lot of stuff around anyway and we are
already moving path_auditor from util.py to scmutil.py for that release.
So this seems like a good opportunity to do such a rename. It also strengthens
the current project policy to avoid underbars in names.
Adds a -i/--inactive flag to the bookmarks command to create or move a
bookmark without making it the current one. This lets you use a bookmark
like a shareable, movable 'tag' and less like a 'branch'.
Thanks to Alexander Solovyov <alexander@solovyov.net> for most of the
work of implementation, and Matt Mackall <mpm@selenic.com> for
suggesting the option name.
These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
Adds a new discovery method based on repeatedly sampling the still
undecided subset of the local node graph to determine the set of nodes
common to both the client and the server.
For small differences between client and server, it uses about the same
or slightly fewer roundtrips than the old tree-based discovery. For
larger differences, it typically reduces the number of roundtrips
drastically (from 150 to 4, for instance).
The old discovery code now lives in treediscovery.py, the new code is
in setdiscovery.py.
Still missing is a hook for extensions to contribute nodes to the
initial sample. For instance, Augie's remotebranches could contribute
the last known state of the server's heads.
Credits for the actual sampler and computing common heads instead of
bases go to Benoit Boissinot.
This drops the options to run arbitrary shell commands within
commits and the option to create a file that gets appended to
in every revision. It now supports to not write file data at
all, which is very fast for generating a pure 00changelog.i
(useful for discovery tests, for instance).
Timings for 1000 linear nodes:
* Old `hg debugbuilddag -o '+1000'` took 4.5 secs.
* New `hg debugbuilddag -o '+1000'` takes 2 secs.
* New `hg debugbuilddag '+1000'` takes 0.8 secs.
(The last one creates only 00changelog.i).
The introduction of the new URL parsing code has created a startup
time regression. This is mainly due to the use of url.hasscheme() in
the ui class. It ends up importing many libraries that the url module
requires.
This fix helps marginally, but if we can get rid of the urllib import
in the URL parser all together, startup time will go back to normal.
perfstartup time before the URL refactoring (707e4b1e8064):
! wall 0.050692 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
current startup time (9ad1dce9e7f4):
! wall 0.070685 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
after this change:
! wall 0.064667 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
This is a long desired cleanup and paves the way for new discovery.
To specify subsets for bundling changes, all code should use the heads
of the desired subset ("heads") and the heads of the common subset
("common") to be excluded from the bundled set. These can be used
revlog.findmissing instead of revlog.nodesbetween.
This fixes an actual bug exposed by the change in test-bundle-r.t
where we try to bundle a changeset while specifying that said changeset
is to be assumed already present in the target. This used to still
bundle the changeset. It no longer does. This is similar to the bugs
fixed by the recent switch to heads/common for incoming/pull.
New argument is silently ignored by both HTTP and SSH servers.
This means we can, for instance, add new flags to getbundle()
to request advanced features (like lightweight-copy-aware bundles),
and older servers will silently ignore this request and send back
a plain bundle.
Example
$ hg clone --jump foo bar
hg clone: option --jump not recognized
hg clone [OPTION]... SOURCE [DEST]
make a copy of an existing repository
options:
-U --noupdate the clone will include an empty working copy (only a
repository)
-u --updaterev REV revision, tag or branch to check out
-r --rev REV [+] include the specified changeset
-b --branch BRANCH [+] clone only the specified branch
--pull use pull protocol to copy metadata
--uncompressed use uncompressed transfer (fast over LAN)
-e --ssh CMD specify ssh command to use
--remotecmd CMD specify hg command to run on the remote side
--insecure do not verify server certificate (ignoring
web.cacerts config)
[+] marked option can be specified multiple times
use "hg help clone" to show the full help text
Motivation for this change
If the user already has specified the command, he probably already knows
the command to some extent. Apparently, he has a problem with the options,
so we show him just the synopsis with the short help and the details about
the options, with a hint on the last line how to get the full help text.
Why is Mercurial better with this change?
Experts who just forgot about the details of an option don't get that
much text thrown at them, while the newbies still get a hint on the last
line how to get the full help text.
Before, you could experience the following strange interaction:
$ hg commit
nothing changed
$ hg merge
abort: outstanding uncommitted changes
which confused at least one user in #mercurial.
_findtags in localrepo checks that nodes exist in the revlog so we
can't get a LookupError here.
The output of 'hg tags' stays the same since tags to unknown nodes
didn't get printed before anyway due to 734bab2916a6.
