This has never worked usefully:
- it can't undo a completely unwanted merge, as it leaves the merge in the DAG
- it can't undo a faulty merge as that means doing a merge correctly,
not simply reverting to one or the other parent
Both of these kinds of merge also require coordinated action among
developers to avoid the bad merge continuing to affect future merges,
so we should stop pretending that backout is of any help here.
As backing out a merge now requires a hidden option, it can't be done
by accident, but will continue to 'work' for anyone who's already
dependent on --parent for some unknown reason.
This is handy if hgext.foo exists but has a bogus "import blah":
previously we just discarded the "No module named blah" error. Now at
least you can see it with --debug. Not perfect, but better than
nothing.
Now 'rollback' after 'import' is less surprising: it rolls back all of
the imported changesets, not just the last one. As an extra added
benefit, you don't need 'rollback -f' after 'import --bypass', which
was an undesired side effect of fixing issue2998 (f9f52d71c33b)..
Note that this is a different take on issue963, which complained that
rollback after importing multiple patches returned the working dir
parent to the starting point, not to the second-last patch applied.
Since we now rollback the entire import, returning the working dir to
the starting point is entirely logical. So this change also undoes
b12d79024900, the fix to issue963, and updates its tests accordingly.
Bottom line: rollback after import was weird before issue963,
understandable since the fix for issue963, and even better now.
This only matters when using the deprecated --base option, and
combining --base with a patch on stdin makes no sense. But it's such
an obvious bug and easy fix that I couldn't pass it by.
The old code printed (with ui.status()) the changeset ID created by
patch N after committing patch N+1, e.g.
applying patch1
applying patch2
applied 1d4bd90af0e4
where 1d4bd90af0e4 is the changeset ID resulting from patch1. That's
just weird. It's also inconsistent: we only reported the changeset ID
when applying >1 patches. And it's inconsistent with 'commit', which
only tells you the new changeset ID in verbose mode. Finally, the
existing code was I18N-hostile, since it concatenated translated
strings.
The new way is to print the just-created changeset ID with ui.note()
immediately after committing it. It also clarifies what the user
message is for easier I18N.
You can get into trouble if you commit, update back to an older
changeset, and then rollback. The update removes your valuable changes
from the working dir, then rollback removes them history. Oops: you've
just irretrievably lost data running nothing but core Mercurial
commands. (More subtly: rollback from a shared clone that was already
at an older changeset -- no update required, just rollback from the
wrong directory.)
The fix assumes that only "commit" transactions have irreplaceable
data, and allows rolling back non-commit transactions as always. But
when rolling back a commit, check that the working dir is checked out
to tip, i.e. the changeset we're about to destroy. If not, abort. You
can get back the old (dangerous) behaviour with --force.
The line content of continued Subject: lines was yet joined via
str.replace('\n\t', ' '), which does not handle continuation via
spaces. So expan the regular expression instead to
handle all allowed forms of mail header line continuation.
It was very elegant that httpsendfile implemented __len__ like a string. It was
however also dangerous because that protocol can't handle sizes bigger than 2 GB.
Mercurial tried to work around that, but it turned out to be too easy to
introduce new errors in this area.
With this change __len__ is no longer implemented at all and the code will work
the same way for short and long posts.
Needed to use 'Py_RETURN_TRUE' instead of 'return Py_True' to avoid
reference count errors which would randomly crash the Python
executable during merge. This only happened when you had something
configured in merge-tools and the merge was large enough.
This is an attempt to fix issue 2451 and its duplicates (2599 and 2949, AFAIK).
Its main idea is that it is only necessary to clean the proxy environment
variables *when* http_proxy is set in the config file (since it takes
precedence over the environment variables). Otherwise, hg shouldn't bother with
them, since they will most likely be used to reach the server.
neither number of 'bytes' in any encoding nor 'characters' is
appropriate to calculate terminal columns for specified string.
this patch modifies MBTextWrapper for:
- overriding '_wrap_chunks()' to make it use not built-in 'len()'
but 'encoding.colwidth()' for columns of string
- fixing '_cutdown()' to make it use 'encoding.colwidth()' instead
of local, similar but incorrect implementation
this patch also modifies 'encoding.py':
- dividing 'colwith()' into 2 pieces: one for calculation columns of
specified UNICODE string, and another for rest part of original
one. the former is used from MBTextWrapper in 'util.py'.
- preventing 'colwidth()' from evaluating HGENCODINGAMBIGUOUS
configuration per each invocation: 'unicodedata.east_asian_width'
checking is kept intact for reducing startup cost.
This re-introduces the unicode conversion what was lost in e5976ee55f4b 5 years
ago and had the comment:
To avoid corrupting multi-byte characters in line, we must wrap
a Unicode string instead of a bytestring.
When setting up the next sample, we always add all of the heads, regardless
of the desired max sample size. But if the number of heads exceeds this
size, then we don't add any more nodes from the still undecided set.
(This is debatable per se, and I'll investigate it, but it's how we designed
it at the moment.)
The bug was that we always added the overall heads, not the heads of the
remaining undecided set. Thus, if #heads>200 (desired sample size), we
did not make progress any longer.
In 55a66b5d9114, _readline was changed to output a space using
raw_input and this was done using sys.stdout directly, not self.fout.
This change broke the command server for JavaHg since it (and other
clients) would see a spurious ' ' on stdout and interpret this as an
unknown channel.
This fixes a regression introduced with the new url handling in 1.9.
This should perhaps be fixed in the url class instead, but that might be too
invasive for a stable bugfix.
This is a workaround for calling ui.prompt(...), typing some character then
hitting backspace which causes the entire line to delete rather than just the
one character. This was seen on Debian using gnome-terminal.
(credits to Mads for the idea)
Python bug can be found here: http://bugs.python.org/issue12833
Newer versions of GCC have aggressive pointer alias optimizations that
might get fooled by our pointer manipulations. These issues shouldn't
be encountered in practice because distutils compiles extensions with
-fno-strict-alias but the code was not valid according to the standard.
urllib2 never handles URIs with credentials, we have to extract them and store
them in the password manager before handing the stripped URI. Half of the
changes deducing the username from the URI in f7ae45a69fcd were incorrect.
Instead, we retrieve the username from the password manager before passing to
readauthforuri().
test-hgweb-auth.py was passing because the test itself was flawed: it was
passing URIs with credentials to find_password(), which never happens.
urllib2 password manager does not strip credentials from URIs registered with
add_password() and compare them with stripped URIs in find_password(). Remove
credentials from URIs returned by util.url.authinfo(). It sometimes works when
no port was specified as the URI host is registered too.
Previously aliases that overrode existing commands would wrap the old alias
on every call to dispatch() (twice actually), which is an obvious re-entrancy
issue for things like the command server or TortoiseHG.
8264e5172141 made sure that paths that seemed to start with a windows drive
letter would not get an extra leading slash.
localpath should thus not try to handle this case by removing a leading slash,
and this special handling is thus removed.
(The localpath handling of this case was wrong anyway, because paths that look
like they start with a windows drive letter can't have a leading slash.)
A quick verification of this is to run 'hg id file:///c:/foo/bar/'.
The [auth] section was ignored when handling URLs like:
http://user@example.com/foo
Instead, we look in [auth] for an entry matching the URL and supplied user
name. Entries without username can match URL with a username. Prefix length
ties are resolved in favor of entries matching the username. With:
foo.prefix = http://example.org
foo.username = user
foo.password = password
bar.prefix = http://example.org/bar
and the input URL:
http://user@example.org/bar
the 'bar' entry will be selected because of prefix length, therefore prompting
for a password. This behaviour ensure that entries selection is consistent when
looking for credentials or for certificates, and that certificates can be
picked even if their entries do no define usernames while the URL does.
Additionally, entries without a username matched against a username are
returned as if they did have requested username set to avoid prompting again
for a username if the password is not set.
v2: reparse the URL in readauthforuri() to handle HTTP and HTTPS similarly.
v3: allow unset usernames to match URL usernames to pick certificates. Resolve
prefix length ties in favor of entries with usernames.
Before: hgweb made it possible to download file content with a content type
detected from the file extension. It would serve .html files as text/html and
could thus cause XSS vulnerabilities if the web site had any kind of session
authorization and the repository content wasn't fully trusted.
Now: all files default to "application/binary", which all important
browsers will refuse to treat as text/html. See the table here:
https://code.google.com/p/browsersec/wiki/Part2#Survey_of_content_sniffing_behaviors
This fixes (issue2907) a crash when using 'hg incoming --bundle' with an empty
remote repo and a non-empty local repo.
This also fixes an unreported bug that 'hg summary --remote' erroneously
reports incoming changes when the remote repo is empty and the local is not.
Also, add a test to make sure issue2907 stays fixed
Some character sets, cp932 (known as Shift-JIS for Japanese) for
example, use 0x41('A') - 0x5A('Z') and 0x61('a') - 0x7A('z') as second
or later character.
In such character set, case collision checking recognizes different
files as CASEFOLDED same file, if filenames are treated as byte
sequence.
win32mbcs extension is not appropriate to handle this problem, because
this problem can occur on other than Windows platform only if
problematic character set is used.
Callers of util.checkcase() use known ASCII filenames as last
component of path, and string.lower() is not applied to directory part
of path. So, util.checkcase() is kept intact, even though it applies
string.lower() to filenames.
On Windows sys.stdout was being replaced with winstdout, which caused
util.system() to redirect its output (due to 388eabdda556). That causes
interactive tools (such as vim) to stop working.
The ui passed to server() is really repo.ui, that is it contains its local
configuration as well.
When running commands that use a different repo than the servers cached repo,
we don't want to use that ui as the baseui for the new repo.
Before, the help text said that Mercurial would assume 'yes' for all
prompts, but this is confusing since many prompts don't have any 'yes'
choice. It now more accurately describes what will happen.
Given an operator ^ that's either postfix or infix and an operator :
that's either prefix or infix, the parser can't figure out the right
thing to do. So we rewrite the expression to be sensible in the optimizer.
util is never imported by any other name than util, so this is mostly just a
simple search and replace from util.localpath to util.urllocalpath (assuming
other uses of util.localpath already has been renamed).
A Subversion subrepo checkout uses a url and --revision which does not do the
correct thing when specifying a revision of a branch that has since been
deleted and recreated. The checkout needs to specify the revision as URL@REV
instead.
In the branches page, branches that are closed and are merged into another
branch are displayed as `inactive'. This patch changes that behaviour to
show these branches as `closed'.
For me, the `closed' attribute is more important than the `inactive'
attribute.
Branches that are not closed, and are merged into other branches will still
be shown as `inactive'.
Branches that are closed, and are not merged into other branches will still
be shown as `closed'.
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
Uncommitted changes (using --all *will* nuke edits):
$ hg revert
abort: no files or directories specified
(uncommitted changes, use --all to discard all changes)
Clean working directory (using --all won't discard anything):
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
There are places in the code that use localrepository.baseui (see hg.remoteui),
we need the ui descriptors (and possibly other things) to be set
correctly on it, so output written to the remoteui descriptors ends up at the
right place.
Before this change, tests such as 'test-bookmarks-pushpull.t' didn't work.
and give a more precise hint for how to revert such a file
I'm using the term 'revision' instead of 'changeset' in this change to be
consistent with the REV we use in the synopsis.
and explicitly warn about uncommitted changes
Examples:
BEFORE:
$ hg par -q
7:e81a2efd53d4
$ hg revert -r 2
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
Clean working directory (revert can be easily undone, no edits to be lost):
$ hg revert -r 2
abort: no files or directories specified
(use --all to revert all files, or 'hg update 2' to update)
Uncommitted changes (revert --all *does* discard edits and is pretty hard to
undo or even impossible if --no-backup is specified):
$ hg revert -r 2
abort: no files or directories specified
(uncommitted changes, use --all to discard all changes, or 'hg update 2' to update)
The existing code seemed to have incorrect assumptions about how parameter
lists are represented by the parser.
Now the match and replace functions have been merged and simplified by using
getlist().
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
$ hg revert
abort: no files or directories specified
(uncommitted merge, use --all to discard all changes, or 'hg update -C .' to abort the merge)
This is a guaranteed by the protocol: clients know they need to read one chunk
off of the 'o' channel and treat that as the hello message.
They should ignore fields they don't recognize so they stay compatible with
new versions of the server in case we decide to add something.
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
AFTER:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
Closing here means we've closed the repo passed to us in the request,
which is not our responsibility.
This is essential for bundlerepo, and possibly other localrepository
subclasses who do something in their close().
output on stderr will also be written to ui.fout, unless sys.__stdout__
is passed in (see util.system), thus not changing previous behavior.
This fixes a bug where hooks run through the command server would mess up
with the command protocol, sending non-channeled data to the client.
No real reason for a client to do this, but still possible.
Previously if the client sent no arguments, a list with an empty string ['']
would be used as the arguments to dispatch, which would cause hg to complain
about an ambiguous command.
Instead, we simply check for no arguments and use an empty list instead (which
is equivalent to invoking hg with no args on the command line).
Old discovery only returned incoming heads, not all of them (for
changegroupsubset). New discovery must always return all of the remote heads
(for getbundle). I failed to properly adjust treediscovery in 43f4c1113c8d
when introducing setdiscovery.
The actual observable problem was 'remote: unsynced changes' when trying
to push a cset on one named branch to a server with a new cset on another
named branch. This scenario is now tested in test-treediscovery.t.
- the power of 2 ones should be kiB, MiB, etc.
- the power of 10 ones (SI standard) should be kB, MB, but we're currently
using the industry traditional units elsewhere
