This is a simple patch to make hg push/hg outgoing print their remote target
path even if the operation fails. I'm not sure if the original behavior was by
design.
This patch also changes one test to reflect the changed behaviour.
In practice this doesn't change anything since ui == repo.ui here, but setting
repo.ui explicitly here is clearer since hg.merge will use repo.ui later on.
Since bookmarks are no longer merged with repo.tags() as of
8e2d23f4bd25, they don't show up in `hg id` as they used to. This adds
them back into the summary that `hg id` prints, and adds a
-B/--bookmarks flag alongside the -t/--tags and -b/--branch options.
Note this introduces a slight backwards-incompatibility: the summary
printed by `hg id` now separates bookmarks from tags with a space, as
seen below, instead of running it into the tags list.
Default summary output:
$ hg id
db815d6d32e6 tip/tag1 bm1/bm2
Output with --bookmarks:
$ hg id --bookmarks
bm1 bm2
See also 5672c9e8202d which adds bookmarks back into `hg summary`.
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.
