This makes `hg pull --update` behave the same wrt the active bookmark as
`hg pull && hg update` does as of 13ea5e437ff8. A helper function,
bookmarks.calculateupdate, is added to prevent code duplication between
postincoming and update.
This change allows setting or deleting multiple bookmarks at once. If more than
one is being set and --inactive is not given, the first one is made active.
This patch resolves a single divergent bookmark if a divergent bookmark exists
in the target revision and it current bookmark is not an ancestor of the target
revision, else it would already be handled by the previous patch in this
series.
Test coverage is added.
This patch is a follow-up to 00b2764d68e4 that resolves divergent bookmarks
between the to-be-forwarded bookmark MARK and the new descendant. This
situation can happen when pulling new changesets, updating to the divergent
bookmark, abandoning the previous changesets with strip, and then moving MARK
to MARK@N.
Test coverage is added.
After this change, moving the active bookmark somewhere other than the
current changeset (i.e., with --rev) deactivates it. Previously it would
remain in .hg/bookmarks.current, which seems like a bug.
Allow a bookmark that points to the current changeset to be made the
active bookmark without requiring --force. Previously, this would've
aborted with:
abort: bookmark 'Z' already exists (use -f to force)
Allow 'hg bookmark MARK', with an existing bookmark MARK, to move the
bookmark forward to the current or specified revision, if the target
revision is a descendant of the revision the bookmark currently points
to. Prints a status message including the revision the bookmark was
formerly at:
$ hg bookmark Z
moving bookmark 'Z' forward from 663762316562
Test coverage is added.
Before this change, 'hg summary' would not show the active bookmark
unless it pointed to the working directory parent. After this change, it
will show it in parentheses, like so:
parent: 18581:f0ff45fe6700 tip
summary: simplify handling of active bookmark
branch: default
bookmarks: [crew]
commit: (clean)
update: (current)
Bookmarks/branches/tags shouldn't be allowed to be integers because that
overlaps with revision numbers. Right now if a user created one they can't
use it anyway because the revision numbers take precedence.
The check only happens when creating a new bookmark/etc from a command so it
shouldn't affect existing bookmarks/branches/tags or importing branches from
git.
This fix was prompted by us having a user create a bookmark named "404" then
accidentally checkout a very old version of our repository.
If the current bookmark (the one listed in .hg/bookmarks.current)
doesn't point to a parent of the working directory, e.g. if it was moved
by a pull, use that as the update target instead of the tipmost
descendent.
A small predicate is (finally) added to the bookmarks module to check
whether the current bookmark is also active.
Before this patch, enabling strict command processing (ui.strict=True)
meant that 'hg bookmark NAME', as referenced several places in the
documentation, would not work. This adds 'bookmark' as an explicit alias
to 'bookmarks'.
The message "updating bookmark @ failed!" in test-bookmarks-pushpull.t
is correct, because the changeset that the @ bookmark points to is not
pushed to the target repository.
This factors out the checks from tags and bookmarks, and newly applies
the same prohibitions to branches. checknewlabel takes a new parameter,
kind, indicating the kind of label being checked.
Test coverage is added for all three types of labels.
Options like --delete and --rename are incompatible with each
other. In this case we abort. We do not abort if the result is a nullop.
Nullops are: '--delete --inactive', '--delete --force'.
If you've got this graph:
0-1-2
\
3
and 3 is checked out, 2 is bookmarked with "broken", and you do "hg
strip 2", the bookmark will move to 3, not 1. That's always struck me
as a bug.
This change makes bookmarks move to the tipmost ancestor of
the stripped set rather than the currently-checked-out revision, which
is what I always expected should happen.
Before this patch undo.bookmarks was created on bookmarks write and
not with other transaction-related files. There were two issues: first
is that if you have changed bookmarks few times after a transaction
happened, rollback will give you a state which can point to
non-existing revision. Second is that if you have not changed
bookmarks after a transaction, rollback will touch your state anyway.
This change also adds `localrepo._writejournal` method, which can be
used by other extensions to save their transaction-related backup in
right time.
Since bookmarks are no longer merged with repo.tags() as of
8e2d23f4bd25, they don't show up in `hg id` as they used to. This adds
them back into the summary that `hg id` prints, and adds a
-B/--bookmarks flag alongside the -t/--tags and -b/--branch options.
Note this introduces a slight backwards-incompatibility: the summary
printed by `hg id` now separates bookmarks from tags with a space, as
seen below, instead of running it into the tags list.
Default summary output:
$ hg id
db815d6d32e6 tip/tag1 bm1/bm2
Output with --bookmarks:
$ hg id --bookmarks
bm1 bm2
See also 5672c9e8202d which adds bookmarks back into `hg summary`.
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.
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.
