ui contains repo specific configuration, so do not use it when there is a repo.
But pass it to hg.peer when there is no repo. Then it only contains global
configuration.
Do not pass ui because it contains the configuration of the repo. It is the
same object as repo.ui.
When a repo is passed to hg.peer, the global configuration is read from
repo.baseui.
Before this patch, repository local configurations are not isolated
between repositories in subrepo tree, because "localrepository"
objects for each subrepositories are created with "ui" instance of the
parent of each ones.
So, local configuration of the parent or higher repositories are
visible also in children or lower ones.
This patch uses "baseui" instead of "ui" to create repository object:
the former contains only global configuration.
This patch also copies 'ui.commitsubrepos' configuration to commit
recursively in subrepo tree, because it may be set in not
"repo.baseui" but "repo.ui".
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.
Before this change a bookmark named "default" or a branch named "@" would
cause the wrong changeset to be checked out.
The change in output of test-hardlinks.t is due to the fact that no unneeded
tag lookups for the tags "@" or "default" happen, therefore the cache file is
not created.
The `%ln` revset substitution does not accept unknown node. We prune unknown
node from potential successors before computing descendants.
This have no impact on the result of this function.
- Descendants of unknown changeset as unknown,
- all successors of unknown changesets are already return by the call who
returned those same unknown changesets,
- unknown changesets are never a valid destination for a bookmark.
These slashes are a hangover from issue3612, fixed in d5787cfaa7cf.
Although the bugfix in that commit is correct, the test it adds
does not replicate the conditions for the bug correctly.
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'.
This allows the user to set different colors for each phase, e.g.
[color]
changeset.public = blue
changeset.draft = green
changeset.secret = red
In addition, this doesn't affect current configuration for custom log.changeset
colors, but rather adds the option for users that want to visually see which
changesets are amendable.
We don't need to compute the set of all branchpoints. We can just check the
number of children that element of subset have. The extra work did not seems to
had particular performance impact but the code is simpler this way.
People were confused by the fact `obstore.precursors` contained marker allowing
to find "precursors" and vice-versa.
This changeset changes their meaning to:
- precursors[x] -> set(markers on precursors edges of x)
- successors[x] -> set(markers on successors edges of x)
Some documentation is added to clarify the situation.
Nullid as successors create multiple issues:
- Nullid revnum is -1, confusing algorithm that use revnum unless you add
special handling in all of them.
- Nullid confuses "divergent" changeset detection and resolution. As you can't
add any successors to Nullid without being in even more troubles
Fortunately, there is no good reason to use nullid as a successor. The only
sensible meaning of "succeed by nullid" is "dropped" and this meaning is already
covered by obsolescence marker with empty successors set.
However, letting some nullid successors to slip in may cause terrible damage in
such algorithm difficult to debug. So I prefer to perform and clear detection of
of such pathological changeset. We could be much smarter by cleaning up nullid
successors on the fly but it would be much for expensive. As core Mercurial does
not create any such changeset, I think it is fine to just abort when suspicious
situation is detected.
Earlier experimental version created such changesets, so there are some out
there. The evolve extension added the necessary logic to clean up its mess.
Maintain a whitelist of commands to infer the repo for instead. The whitelist
contains those commands that take file(s) in the working dir as arguments.
This changeset treats the bookmark "@" as a special case for the naming of
divergent bookmarks, as per the tables below. For the <no alias> case, the
actual suffix will vary, depending on what suffixes are already in use.
Before:
Bookmark | Remote | Divergent Bookmark
--------------------------------------
foo | bar | foo@bar
foo | <no alias> | foo@1
@ | bar | @@bar
@ | <no alias> | @@1
After:
Bookmark | Remote | Divergent Bookmark
--------------------------------------
foo | bar | foo@bar
foo | <no alias> | foo@1
@ | bar | @bar
@ | <no alias> | @1
This case is likely to be more common now that c1644655c164 has made the "@"
bookmark have special meaning to clone.
The change in behavior was discussed on the mailing list in the thread below:
http://markmail.org/thread/rwedgxp7le5j2h2f
Before this patch, there is no information about whether help document
is fully displayed or not.
So, some users seem to misunderstand "-v" for "hg help" just as "the
option to show list of global options": experience on "hg help -v" for
some commands not containing verbose containers may strengthen this
misunderstanding.
Such users have less opportunity for noticing omitted help document,
and this may cause insufficient understanding about Mercurial.
This patch indicates help omitting, if help document is not fully
displayed.
For command help, the message below is displayed at the end of help
output, if help document is not fully displayed:
use "hg -v help xxxx" to show more complete help and the global
options
and otherwise:
use "hg -v help xxxx" to show the global options
For topics and extensions help, the message below is displayed, only
if help document is not fully displayed:
use "hg help -v xxxx" to show more complete help
This allows users to know whether there is any omitted information or
not exactly, and can trigger "hg help -v" invocation.
This patch causes formatting help document twice, to switch messages
one for omitted help, and another for not omitted. This decreases
performance of help document formatting, but it is not mainly focused
at help command invocation, so this wouldn't become problem.
This applies the same logic as used for `obsolete` and `unstable` changesets.
Refuse to push them without force.
We'll probably want to factor this logic with two new functions
`pctx.troubled()` and `ctx.troubles()`. But I'm waiting for the third
"trouble" to make it into core.
