When you rebased with a currently active bookmark, that bookmark would
always point at the new tip, regardless of what revision it pointed at
before the rebase.
All bookmarks will now point at the equivalent post-rebase commit.
However, the currently active bookmark will cease to be active unless
it points at the new tip post-rebase. Rebase will always leave the
new tip as the working copy parent, which is incompatible with having
an active bookmark that points at some other revision. The common
case should be that the active bookmark will point at the new tip
post-rebase.
This replicates the strategy of rebase, which postpones setparents and
duplicatecopies after checking the merge stats.
Without the second parent, resolve cannot redo merge.
dbc9f6aea991 introduced "svn info TARGET@REV" to determine if a certain
path exists in the specified revision, but in svn 1.5 the error message
"Not a valid URL" yields exit code 0 so the error is not caught.
Use "svn list TARGET@REV" instead which works with svn 1.5 and is even
faster in some situations.
The previous error message had two issues: The first issue was that it
wasn't, in fact, an error but a warning, even though it described a
fatal error condition preventing the successful completion of the
command. The second was that it didn't mention the immutable
changesets, leaving the user guessing at the true cause of the error.
The main downside to this change is that we now get an 'abort: can't
abort...' message which technically contradicts itself. In this case,
I blame that on the two uses we have for the word; if it weren't for
backwards compatibility, we could make util.Abort print out 'error:
<whatever>'.
Popen does not consider "foo.cmd" equivalent to "foo" on Windows.
Unfortunately, the default MSYS Git installation installs only "git.cmd" into
the path by default. This patch probes for both possible names on Windows.
This specific cd .. leaves the base directory of the test ($TESTTMP).
Removing it avoids that test artifacts (e.g. files) are created
outside of the base directory.
When requesting files using statichttprepo.httprangereader, a request for the
entire file is sent with a Range: bytes=0- header. This causes problems with
web servers such as Cherokee that return an HTTP 416 when an empty file is
requested in this way, which in turn cause some repository clone attempts to
fail. This patch omits the Range header when the entire file is being
requested, which fixes the problem.
When applying a patch renaming/copying 'a' to 'b' on a revision where
'a' does not exist, the patching process would abort immediately,
without processing the remaining hunks and without reporting it. This
patch makes the patching no longer abort and possible hunks applied on
the copied/renamed file be written in reject files.
b67b333b0d8a attempted to force the filecaches in localrepo to reload
everything after a rollback. But simply clearing _filecache isn't enough,
invalidate() needs to be called before/after. localrepo._rollback calls
invalidate() already, so we clear the map right afterwards which ensures
everything will be reread.
'exact' match objects are sometimes created with a non-list 'pattern'
argument:
- using 'set' in queue.refresh():hgext/mq.py
match = scmutil.matchfiles(repo, set(c[0] + c[1] + c[2] + inclsubs))
- using 'dict' in revert():mercurial/cmdutil.py (names = {})
m = scmutil.matchfiles(repo, names)
'exact' match objects return specified 'pattern' to callers of
'match.files()' as it is, so it is a non-list object.
but almost all implementations expect 'match.files()' to return a list
object, so this may causes problems: e.g. exception for "+" with
another list object.
this patch ensures that '_files' of 'exact' match objects is a list
object.
for non 'exact' match objects, parsing specified 'pattern' already
ensures that it it a list one.
The alias expansion code it changed from:
1- Get replacement tree
2- Substitute arguments in the replacement tree
3- Expand the replacement tree again
into:
1- Get the replacement tree
2- Expand the replacement tree
3- Expand the arguments
4- Substitute the expanded arguments in the replacement tree
and fixes cases like:
[revsetalias]
level1($1, $2) = $1 or $2
level2($1, $2) = level1($2, $1)
$ hg log -r "level2(level1(1, 2), 3)"
where the original version incorrectly aborted on infinite expansion
error, because it was confusing the expanded aliases with their
arguments.
The current revset alias expansion code works like:
1- Get the replacement tree
2- Substitute the variables in the replacement tree
3- Expand the replacement tree
It makes it easy to substitute alias arguments because the placeholders
are always replaced before the updated replacement tree is expanded
again. Unfortunately, to fix other alias expansion issues, we need to
reorder the sequence and delay the argument substitution. To solve this,
a new "virtual" construct called _aliasarg() is introduced and injected
when parsing the aliases definitions. Only _aliasarg() will be
substituted in the argument expansion phase instead of all regular
matching string. We also check user inputs do not contain unexpected
_aliasarg() instances to avoid argument injections.
