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.
This improves the misleading error message
$ hg identify
abort: there is no Mercurial repository here (.hg not found)!
to the more explicit
$ hg identify
abort: requirement 'fake' not supported!
for all commands in commands.optionalrepo, which includes the identify
and serve commands in particular.
This is for the case when a new entry in .hg/requires will be defined
in a future Mercurial release.
Previously, when rolling back a transaction, some users could be confused
between the level to which the store is rolled back, and the new parents
of the working directory.
$ hg rollback
rolling back to revision 4 (undo commit)
With this change:
$ hg rollback
repository tip rolled back to tip revision 4 (undo commit)
working directory now based on revision 2 and 1
So now the user can realize that the store has been rolled back to an older
tip, but also that the working directory may not on the tip (here we are
rolling back the merge of the heads 2 and 1)
Invalid requests could give an unhandled ErrorResponse.
Now this ErrorResponse is handled like other ErrorResponses so the client gets
an error message which also is logged on the server.
This changes the prompts on git subrepos to show only the first seven
digits of git changeset IDs (as git's command line does):
$ hg update
subrepository sources for s differ (in checked out version)
use (l)ocal source (32a3438) or (r)emote source (da5f5b1)?
We restrict : to 1. make it easer to convert bookmarks to git branches,
2. use : later for a syntax to push a local bookmark to a remote bookmark
of a different name. \0, \n, \r are fobbidden they are used to separate
bookmarks in the bookmark file.
This change breaks backward compatbility as ':' was an allowed character in
previous versions.
Consider a repository with a single subrepository. The changesets in
the main repository reference the subrepository changesets like this:
m0 -> s0
m1 -> s1
m2 -> s2
Starting from a state (m1, s0), doing 'hg update m2' in the main
repository will yield a conflict: the subrepo is at revision s0 but
the target revision says it should be at revision s2.
Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus
ignore the conflict between the working copy and the target revision.
With this change, the user is prompted to resolve the conflict by
choosing which revision he wants. This is consistent with 'hg merge',
which also prompts the user when it detects conflicts in the merged
.hgsubstate files.
The prompt looks like this:
$ hg update tip
subrepository sources for my-subrepo differ
use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
The default behaviour is to commit subrepositories with uncommitted changes. In
my experience this is usually undesirable:
- Changes to dependencies are often debugging leftovers
- Real changes should generally be applied on the source project directly,
tested then committed. This is not always possible, subversion subrepos may
include only a small part of the source project, without the tests.
Setting ui.commitsubrepos=no will now abort commits containing such modified
subrepositories like:
$ hg --config ui.commitsubrepos=no ci -m msg
abort: uncommitted changes in subrepo sub
I ruled out the hook solution because it does not easily take --include/exclude
options in account. Also, my main concern is whether this flag could cause
problems with extensions. If there are legitimate reasons for callers to
override this behaviour (I could not find any), they might either override at ui
level, or we could add an argument to localrepo.commit() later.
v2:
- Renamed ui.commitsubs to ui.commitsubrepos
- Mention the configuration entry in hg help subrepos
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.)
The patch changes the output of "hg diff --stat" when one file whose filename
has spaces has changed, making it get the full filename instead of just the
substring between the last space and the end of the filename.
It also changes the diffstat generated by "hg email -d" when one of the commit
messages starts with "diff". Because of the regex used to parse the filename,
the diffstat generated by "hg email -d" will still be not correct if a commit
message starts with "diff -r ".
Before the patch Mercurial has the following behavior:
$ echo "foobar">"file with spaces"
$ hg add "file with spaces"
$ hg diff --stat
spaces | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
$ hg diff --git --stat
file with spaces | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
After the patch:
$ echo "foobar">"file with spaces"
$ hg add "file with spaces"
$ hg diff --stat
file with spaces | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
$ hg diff --git --stat
file with spaces | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Before the patch:
$ hg add mercurial/patch.py tests/tests-diffstat.t
$ hg commit -m "diffstat: fix parsing of filenames"
$ hg email -d --test tip
This patch series consists of 1 patches.
diffstat: fix parsing of filenames
[...]
filenames | 0
mercurial/patch.py | 6 ++++--
tests/test-diffstat.t | 17 +++++++++++++++++
3 files changed, 21 insertions(+), 2 deletions(-)
[...]
After the patch:
$ hg email -d --test tip
This patch series consists of 1 patches.
diffstat: fix parsing of filenames
[...]
mercurial/patch.py | 6 ++++--
tests/test-diffstat.t | 17 +++++++++++++++++
3 files changed, 21 insertions(+), 2 deletions(-)
[...]
We can't assume that all pushable patches early in the series have already been
applied. If a hg qselect is done while you already have patches applied, some
patches with guards may now be pushable, even though they come earlier in the
series.
So instead of checking only applied patches, explicitly check where we are in
the series against the position of the patch we want to qpush to.
Add empty repository.close() and call it in dispatch.
Remove bundlerepository.__del__(), merging it into bundlerepository.close(),
which overrides repository.close().
http://docs.python.org/reference/datamodel.html says:
"It is not guaranteed that __del__() methods are called for objects that
still exist when the interpreter exits."
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.
This makes 'hg update --clean' behave the same way for both kinds of
subrepositories. Before Subversion subrepos did not take the clean
parameter into account, but just updated to the given revision and
merged uncommitted changes into that.
Known fingerprints of HTTPS servers can now be configured in the
hostfingerprints section. That makes it possible to verify the identify of web
servers without configuring and trusting the CA chain.
Limitations:
* Portnumbers are ignored, just like with ordinary certificates.
* Host name matching is case sensitive.
A subversion project revisions are a subset of the repository revisions, you
can ask subversion to update a working directory from one revision to another
without changing anything. Unfortunately, Mercurial will think the
subrepository has changed and will commit it again. To avoid useless commits,
we compare the subrepository state to its actual "parent" revision. To ensure
ascending compatibility with existing subrepositories which might reference
fake revisions, we also keep comparing with the subrepo working directory
revision.
NOTE: not sure if this should go in stable or not.
SSLSocket.getpeercert() returns tuple containing unicode for 'subject'.
Since Mercurial does't support IDN at all, it just returns error for non-ascii
certname.
This makes 'hg update --clean' behave the same way for all three kinds
of subrepositories [hg, svn, git]. Before git subrepos did not take
the clean parameter into account, but just updated to the given
revision and merged uncommitted changes into that.
This turns the prompt sequence from something like:
$ examine changes to foo?
$ record change 1/4 to foo?
$ record change 2/4 to foo?
$ examine changes to bar?
$ record change 4/4 to bar?
into:
$ examine changes to foo?
$ record change 1/3 to foo?
$ record change 2/3 to foo?
$ examine change to bar?
$ record change 3/3 to bar?
The generation of cache files like tags.cache and branchheads.cache is not an
actual reflection of things changing in the whole of the .hg directory (like eg
a commit or a rebase or something) but instead these cache files are just part
of bookkeeping. As such its convienant to allow various clients to ignore file
events to do with these cache files which would otherwise cause a double
refresh. Eg one refresh might occur after a commit, but the act of refreshing
after the commit would cause Mercurial to generate a new branchheads.cache which
would then cause a second refresh, for clients.
However if these cache files are moved into a directory like eg .hg/cache/ then
GUI clients on OSX (and possibly other platforms) can happily ignore file events
in this cache directory.
- stdin was not forwarded in testrm1 and testrm2
- Forwarding content with EOL using command substitution (`foo`) does not work
correctly, the lines are joined together which breaks the prompt readline.
- EOFError is raised in ui.prompt() if the input is too short on Linux while
OSX treats it as an empty line.
using hg clone svn://anonsvn.kde.org/home/kde/trunk kde ... with progress
yields 3008/1210830 1314h56m, which is unusable.
Add code to switch to days at 30 hours, to weeks at 15 days, and to years
at 55 weeks. A day has 24 hours, a week has 7 days, and a year has 52 weeks.
Months are intentionally omitted because they do not have a fixed length. The
Use of 52 weeks is a known and understandable estimate for a year.
It might make sense to spell our year to alert people when progress is
impractical, but...
It tries to convert localstr to unicode before truncating.
Because we cannot assume that the given text is encoded in local encoding,
it falls back to raw string in case of unicode error.
In a date like 10:30, there are two underspecified ends: the specific
end (seconds) and the broad end (day, month, year). When matching
"10:30", we need to allow the specific end to go from 0 to 59 seconds,
while the broad end is assumed to be today's date.
Similar handling applies for a date range like "Mar 1": year is fixed
to today, any time matches.
Tracked files starting with a period in the name begin with '~2e' in the
store for the dotencode repository format, which is encoded as '%7E2e' in
URLs when accessing the repo over static-http.
The spaces in filenames are encoded with %20 in URLs.
See also issue 2566.
- signal handlers take two arguments, not one
- add missing import sys
Before this patch, the
$ kill $!
at the end of the test just caused a hidden traceback, sys.exit(0) was not
executed.
The swallowed traceback was:
Traceback (most recent call last):
File "dumb.py", line 10, in <module>
run()
File "dumb.py", line 7, in run
httpd.serve_forever()
File "/usr/lib/python2.6/SocketServer.py", line 224, in serve_forever
r, w, e = select.select([self], [], [], poll_interval)
TypeError: <lambda>() takes exactly 1 argument (2 given)
The actual order of dictionary items is implementation-defined in
Python, and differs between CPython and PyPy. With this change,
test-hooks.t passes with PyPy.
Mercurial will verify HTTPS server certificates if web.cacerts is configured,
but it will by default silently not verify any certificates.
We now warn the user that when the certificate isn't verified she won't get the
security she might expect from https:
warning: localhost certificate not verified (check web.cacerts config setting)
Self-signed certificates can be accepted silently by configuring web.cacerts to
point to a suitable certificate file.
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.
Do not pass reject file content to patchfile.writelines() to:
- Avoid line endings transformations
- Avoid polluting overriding implementations with unrelated data. They should
override write_rej() to deal or ignore reject files properly.
Bug report, analysis and original patch and test by
Shun-ichi GOTO <shunichi.goto@gmail.com>
If Linux is asked to open a filename with a trailing directory separator,
e.g. "foo/", the open fails with EISDIR. On AIX, the open succeeds, opening
file "foo". This causes test-mq-qnew to fail on AIX.
Fix by adding 'ends with directory separator' to the conditions checked
by the path auditor. Change test to expect auditor fail message.
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.
This patch conforms gitsubrepo code to the variable naming scheme of the other
subrepo implementations. All user-facing path references should be relative
to the root repository.
This patch prevents MQ from creating an inconsistent subrepo state. If
the .hgsub file has been changed, and none of the subrepos have
uncommitted changes, creating or updating a patch (using qnew, qrefresh,
or qrecord) will update .hgsubstate accordingly.
If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord
will abort.
Thanks to pmezard for proposing this solution.
issue2538 gives a case where a changeset is merged with its child (which is on
another branch), and to my surprise the result is a real merge with two
parents, not just a "fast forward" "merge" with only the child as parent.
That is essentially the same as issue619.
Is the existing behaviour as intended and correct?
Or is the following fix correct?
Some extra "created new head" pops up with this fix, but it seems to me like
they could be considered correct. The old branch head has been superseeded by
changes on the other branch, and when the changes on the other branch is merged
back to the branch it will introduce a new head not directly related to the
previous branch head.
(I guess the intention with existing behaviour could be to ensure that the
changesets on the branch are directly connected and that no new heads pops up
on merges.)
1) hg cp symlink copy -> copy is a symlink.
2) cp symlink copy; hg cp -A symlink copy -> copy is a regular file.
In the second case we have to follow the symlink to its target
to find out whether we have to unexpand keywords in the copy.
Add test covering the case where the copied link's target is ignored
by keyword but has content which would match the regex for expanded
keywords to check whether we indeed leave the destination alone.
This patch avoids empty commit when .hgsubstate is dirty. Empty commit
was caused by .hgsubstate being updated back to the state of the
working copy parent when committing, if a user had changed it manually
and not made any changes in subrepositories.
The subrepository state from the working copies parent is compared
with the state calculated as a result of trying to commit the
subrepositories. If the two states are the same, then return None
otherwise the commit is just done.
The line: "committing subrepository x" will be written if there is
nothing committed, but .hgsubstate is dirty for x subrepository.
The two tests that used filtercr.py already used a slightly different
version, which explains why test-convert-svn-move.t changed after
switching to using $TESTDIR/filtercr.py.
8aa8db6deb47 moved the subdirectory match inside the repository match
loop. A virtual path existing/path/invalid/path would then match
existing/path, and generate a wrong index page.
Additions to test-mq-qrefresh.t in 0880564992de (mq: ignore subrepos
(issue2499)) were originally based on a version prior to 42fb7ef18fb4
(subrepo: handle missing subrepo spec file as removed). This fixes a
test failure that resulted from the former being applied after the
latter, noticed by abuehl.
The case
$ hg clone a ''
already aborted before c1e68cd8cfa8, whereas
$ hg clone --pull a ''
tripped the fixed issue2528.
Both basic cases are expected to fail with an abort.
If MQ allows modifying .hgsub or .hgsubstate in a patch, it can easily
lead to an inconsistent subrepo state. This patch prevents qrefresh from
adding any modifications to .hgsub or .hgsubstate to a patch. The user
is warned that these files are not included in the patch.
The tests test both the slightly irrational and the pathological cases.
Regression from 9f0026001bfd. That previous commit is not supposed
to affect log calls without --follow, so we step out of this
codepath if follow is not True, and it's enough to fix the
regression.
When --follow is given, we fix the issue by taking into account
changesets that have a rev > maxrev to build the filegraph: even if
those files are not included in the final result, it's still needed
to walk correctly the graph from the end of the filelog to minrev, to
track accurately renames.
While this situation should never under normal use, some real
life repos sometimes contain such changesets (older hg versions,
broken rebases, etc...)
hgweb was displaying an "Internal error" in this case, and graphlog
displayed a redundant branch all the way to null: it does not cost us
much to just ignore this extra parent when constructing the DAG.
We were not returning the correct result if nullrev was in revs, as we
are checking parent(currentrev) != nullrev before yielding currentrev
test-convert-hg-startrev was wrong: if we start converting from rev -1 and
onwards, all the descendants of -1 (full repo) should be converted.
This makes test output less ambiguous.
Failing test output will be escaped and marked up if necessary. A Python
string-escape compatible encoding is used, but not everything is encoded -
especially not \n and \t and '.
Output chunks without a trailing LF will now work but get (no-eol) appended.
This change mostly moves code around so we can handle that an output line
starts with data from previous command, followed by salt and the next command.
203ffed27f86 made this simple test-test.t succeed silently:
$ printf ' $ true' > test-test.t
but did not give a usable .err in this case:
$ printf ' $ false' > test-test.t
The missing LF will now be fixed in the test output and it will thus give a
test failure and a solution in the .err file.
This prevents spurious errors when a changeset hash happens to match
the port number. Before, this invocation gave a test failure:
$ ./run-tests.py test-log.t --port 24427
ERROR: /home/mg/src/mercurial-crew/tests/test-log.t output changed
--- /home/mg/src/mercurial-crew/tests/test-log.t
+++ /home/mg/src/mercurial-crew/tests/test-log.t.err
@@ -626,12 +626,12 @@
$ hg log -b default
changeset: 2:c3a4f03cc9a7
- parent: 0:24427303d56f
+ parent: 0:$HGPORT303d56f
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: commit on default
...
The current implementation of colwidth was treating 'A'mbiguous
characters as wide, which was incorrect in a non-East Asian context.
As per http://unicode.org/reports/tr11/#Recommendations, we should
instead default to 'narrow' if we don't know better. As character
width is dependent on the particular font used and we have no idea
what fonts are in use, this recommendation applies.
This introduces HGENCODINGAMBIGUOUS to get the old behavior back.
Previously, we'd reset the entire progress bar state when a topic was
completed, even if it wasn't the outermost progress topic. Now we
print the state of the next progress topic on the stack if one is left
rather than reset the progress bar.
Currently, cmdutil.make_file() will return a freshly made file handle,
except when given a pattern of '-'. If callers would want to close the
handle, they would have to make sure that it's neither sys.stdin or
sys.stdout. Instead, returning a duplicate of either of the two
ensures that make_file() lives up to its name and creates a new
file handle regardless of the input.
This uses the same strategy as progress for pulls, estimating manifests
based on changeset count and estimating file count by files list in
each changeset.
This continues the strategy of separation between hg pull and hg update in
git subrepos by only dealing with git's branches on an update. This behavior
tries to cover the bare essentials of the semantics of git pull in the subrepo
when the parent repo does hg pull and hg update.
The stringification of sys.stderr is different in PyPy:
$ pypy -c 'import sys; print sys.stderr'
<open file '<fdopen>', mode 'w' at 0x00a42080>
$ python -c 'import sys; print sys.stderr'
<open file '<stderr>', mode 'w' at 0x10025a270>
The test will now ignore the exact value between the angle brackets.
Prior to unification, the test contained an 'echo $?' line. This line
was removed during unification, but the 'echo 255' line that faked it
when FIFO support is absent was not.
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.
This patch adds an '--exact/-e' option to qpush that will try to push the
patches in the correct location in the DAG. Specifying this option does the
following:
* If --move is specified, abort. It makes no sense to move a patch to the front
of the queue and try to apply it to its parent, because its parent is one of
the patches we just moved it in front of!
* If patches are already applied, abort. We don't want patch changesets
scattered throughout the DAG.
* If local changes are present, abort unless --force is used, as usual.
* Find the first patch we're going to push (if we're pushing multiple patches
with a target or --all).
* If that patch doesn't have a parent, abort, obviously.
* If the parent doesn't exist in the repo, abort. Something is wrong.
* Update to the parent, then continue pushing the patches as normal.
Avoids calls to git push when the revision is already known to be
in the remote repository. Now, when using a read-only git subrepo,
git will never need to talk to its upstream repository.
The Python 'is' operator compares object identity, so it should
definitely not be applied to string or number literals, which Python
implementations are free to represent with a temporary object.
This should catch the following kinds of bogus expressions (examples):
x is 'foo' x is not 'foo'
x is "bar" x is not "bar"
x is 42 x is not 42
x is -36 x is not -36
As originally proposed by Martin Geisler, amended with catching
negative numbers.
This patch adds a case to test-hardlinks.t which demonstrates that
hardlinks in the working directory are broken up (using 'hg update').
Motivation for this patch:
'hg help clone' shows copying repositories *and* the working directory
using 'cp -al', creating hardlinks in the *working directory* too (not
just in the store).
Note that we can't use 'cp -al' since for example MacOS X doesn't
support these options on cp. I'm thus using the same trick as in
test-hardlinks-safety.t for creating hardlinks in the working dir.
This enables minirst to parse and print option lists which have both
long and short options. Before, we could only parse option lists with
long options.
When --debug is given to the test runner, run() returns (retcode, None).
Do not try to use None output as a string, and return directly, similarly
as other testers.
With this patch applied, Mercurial will list the hashes of new remote heads
if push --debug aborts because of new remote heads (option -f/--force not set).
Example:
$ hg push --debug repo1
using http://example.org/repo1
http auth: user johndoe, password not set
sending between command
pushing to http://example.org/repo1
sending capabilities command
capabilities: changegroupsubset stream=1 lookup pushkey unbundle=HG10GZ,HG10BZ,HG10UN branchmap
sending heads command
searching for changes
common changesets up to 187dd3f0a37d
sending branchmap command
new remote heads on branch 'default' <- new output line
new remote head 5862c07f53a2 <- new output line
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
Compare to without --debug (not changed by this patch, including it here
for reference purposes only):
$ hg push repo1
pushing to http://example.org/repo1
searching for changes
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
Motivation for this change:
'hg outgoing' may list a whole lot of benign changesets plus an odd changeset
that will trigger the "new remote heads" abort. It can be hard to spot that
single unwanted changeset (it may be an old forgotten experiment, lingering
in the local repo).
"hg log -r 'heads(outgoing())'" might be useful, but that also lists a head
that may be benign on push.
Inside prepush(), we already know which heads are causing troubles on 'hg push'.
Why not make that info available (at least on --debug)?
This would also be helpful for doing remote support, as the supporter can ask
the user to paste the output of 'hg push --debug' on error and then ask further
questions about the heads listed.
- Handle 'subset' argument
- Stop returning the null rev from p1 and parents, as in the non-dirstate case
- Order parents as in the non-dirstate case (ascending revs)
This patch makes the 'set' argument to revset function parents() optional.
Like p1() and p2(), if no argument is given, returns the parent(s) of the
working directory.
Morally equivalent to 'p1()+p2()', as expected.
This patch makes the 'set' argument to revset functions p1() and p2()
optional. If no argument is given, p1() and p2() return the first or second
parent of the working directory.
If the working directory is not an in-progress merge (no 2nd parent), p2()
returns the empty set. For a checkout of the null changeset, both p1() and
p2() return the empty set.
Use field list instead of option list in convert help, because the
option list format used, with defaults and type of argument is not
supported by docutils.
The test sometimes failed because f4.bat wasn't dirty. I'm not sure whether it
should or shouldn't be dirty, but the extension is broken and deprecated and we
just want to see the deprecation warning, so now we just avoid showing the
dirtyness.
When issuing `hg pull -r REV` in a repo with no common ancestor with the
remote repo, the message 'requesting all changes' is printed, even though only
the changese that are ancestors of REV are actually requested. This can be
confusing for users (see
http://www.selenic.com/pipermail/mercurial/2010-October/035508.html).
This silences the message if (and only if) the '-r' option was passed.
- dirstate of overwritten files must be forced to normal
with kwexpand/kwshrink, not commit.
- recorded files must be weeded before overwriting.
- add test cases.
