The logic that decides where to update according to the active bookmark
location (when not on ".") was setting the rev to update to before we process
--date. This lead to --date processing aborting because of duplicated
specification.
We reorder the two pieces of code and add a test for this.
For some time, bookmark can and should be moved in the transaction. This
changeset migrates the 'hg bookmarks' commands to use a transaction.
Tests regarding rollback and transaction hooks are impacted for
obvious reasons. Some have to be slightly updated to keep testing the
same things. Some can just be dropped because they do not make sense
anymore.
The phase of the pending commit depends on the parent of the working directory
and on the phases.newcommit configuration.
First, this information rather depend on the commit line which describe the
pending commit.
Then, we only want to be advertised when the pending phase is going to be higher
than the default new commit phase.
So the format will change from
$ hg summary
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge)
update: (current)
phases: 1 secret (secret)
to
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret)
update: (current)
phases: 1 secret
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
The number of draft and secret changesets are currently not summarized.
This is an important information because the number of drafts give some rough
idea of the number of outgoing changesets in typical workflows, without needing
to probe a remote repository. And a non-zero number of secrets means that
those changeset will not be pushed.
If the repository is "dirty" - some draft or secret changesets exists - then
summary will display a line like:
phases: X draft, Y secret (public)
The phase in parenthesis corresponds to the highest phase of the parents of
the working directory, i.e. the current phase.
By default, the line is not printed if the repository is "clean" - all
changesets are public - but if verbose is activated, it will display:
phases: (public)
On the other hand, nothing will be printed if quiet is in action.
A few tests have been added in test-phases.t to cover the -v and -q cases.
Before this patch, "bookmark()", "named()" and "tag()" predicates
raise "Abort", when the specified pattern doesn't match against
existing ones.
This prevents "present()" predicate from continuing the query, because
it only catches "RepoLookupError".
This patch raises "RepoLookupError" instead of "Abort", to make
"present()" predicate continue the query, even if "bookmark()",
"named()" or "tag()" in the sub-query of it are aborted.
This patch doesn't contain raising "RepoLookupError" for "re:" pattern
in "tag()", because "tag()" treats it differently from others. Actions
of each predicates at failure of pattern matching can be summarized as
below:
predicate "literal:" "re:"
---------- ----------- ------------
bookmark abort abort
named abort abort
tag abort continue (*1)
branch abort continue (*2)
---------- ----------- ------------
"tag()" may have to abort in the (*1) case for similarity, but this
change may break backward compatibility of existing revset queries. It
seems to have to be changed on "default" branch (with "BC" ?).
On the other hand, (*2) seems to be reasonable, even though it breaks
similarity, because "branch()" in this case doesn't check exact
existence of branches, but does pick up revisions of which branch
matches against the pattern.
This patch also adds tests for "branch()" to clarify behavior around
"present()" of similar predicates, even though this patch doesn't
change "branch()".
This behavior didn't make much sense and interacts badly with things
that use unbundle internally like shelve. Presumably, the original
rationale was that since bundles didn't contain bookmarks, this gave a
sense of keeping bookmarks up-to-date like would happen with a
corresponding pull. However, since it only updated the current active
bookmark, and bare update already did that anyway, this is pretty
slim.
Notably, the corresponding test actually works better without this
feature.
When updating to a bookmark, mention that the bookmark is now
active. This is a reminder that update does not move the
current bookmark if an explicit target is given - instead
it activates that target.
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.