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.
This bug may be caused by file subgraphs have more than two parents
per node. I have no idea if this fix is correct as the graphlog code
is mysterious, but it seems to be fine on the available test case.
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.
