# skip-blame because this was mechanically rewritten the following script. I
ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t
ones appear to be, and they run without addition failures on both Windows and
Linux.
import argparse
import os
import re
ap = argparse.ArgumentParser()
ap.add_argument('path', nargs='+')
opts = ap.parse_args()
globre = re.compile(r'^(.*) \(glob\)(.*)$')
for p in opts.path:
tmp = p + '.tmp'
with open(p, 'rb') as src, open(tmp, 'wb') as dst:
for line in src:
m = globre.match(line)
if not m or '$LOCALIP' in line or '*' in line:
dst.write(line)
continue
if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
dst.write(line)
continue
dst.write(m.group(1) + m.group(2) + '\n')
os.unlink(p)
os.rename(tmp, p)
.. feature::
New `commands.update.check` feature to adjust constraints on when
`hg update` will allow updates with a dirty working copy.
also
.. bc::
The `experimental.updatecheck` name for the new `commands.update.check`
feature is now deprecated, and will be removed after this release.
Differential Revision: https://phab.mercurial-scm.org/D1070
Upon pull or unbundle, we display a message with the range of new revisions
fetched. This revision range could readily be used after a pull to look out
what's new with 'hg log'. The algorithm takes care of filtering "obsolete"
revisions that might be present in transaction's "changes" but should not be
displayed to the end user.
Currently when we have multiple heads on the same branch, update tells us that
there some more heads for the current branch but does not tells us the head to
which the repository has been updated to. It makes more sense showing the
head we updated to and then telling there are some more heads.
This allows the user to set e.g. experimental.updatecheck=abort to
abort update if the working directory is dirty, but still be able to
override the behavior with e.g. --merge when needed.
I considered adding a --mergelinear option to get back the old
behavior even when experimental.updatecheck=abort is set, but I
couldn't see why anyone would prefer that over --merge.
The default is read in hg.updatetotally(), which means it also applies
to "hg pull -u" and "hg unbundle -u".
Before this patch, "hg pull -u" with a target doesn't deactivate a current
active bookmark, which doesn't match with the explicit destination of the
update, even though bare "hg update" does so.
A "target" can be provided through:
- option --rev ANOTHER
- option --branch ANOTHER
- source URL#ANOTHER
Before this patch, "hg pull -u" with a target doesn't activate a bookmark, which
matches with the explicit destination of the update, even though bare "hg
update" does so.
A "target" can be provided through:
- option --rev BOOKMARK
- source URL#BOOKMARK
Bare 'hg update' now brings you to the tipmost descendant (on the same branch).
Leaving the user on the same topological branch. The previous behavior, updating
to the tipmost changeset on the same branch could lead to jump from a
topological branch to another. This was confusing and impractical. As the only
conceivable reason for the old behavior have been address by the recently
introduce message about other heads, we can "safely" change this behavior
All test changes have been reviewed and seen a valid consequences.
Before this patch hg pull -u on UpdateAbort error returned
0 value to the system. This patch fixes this by reraising
UpdateAbort with updated error msg.
Many tests didn't change back from subdirectories at the end of the tests ...
and they don't have to. The missing 'cd ..' could always be added when another
test case is added to the test file.
This change do that tests (99.5%) consistently end up in $TESTDIR where they
started, thus making it simpler to extend them or move them around.
Previously, pull would not update if new branch heads were received,
whereas pull && update would move to the tipmost branch head.
Also change the "crosses branches" abort in merge.update from
"crosses branches (merge branches or use --check to force update)"
to
"crosses branches (merge branches or update --check to force update)"
since it can no longer assume the user is running hg update.
