This patch puts all these changeset "tags" into one template shared everywhere
in paper and coal themes. But it should be noted that some of the templates had
different sets of tags, in some cases it was intended, in others - most likely
not.
First, what's up with all these different ways to get changeset's branch. There
are actually 3 ways to do it in hgweb, they can all be seen in this patch;
"branches", "inbranch" and "branch". They are all lists that consist of 1 or 0
items:
- "branches" has ctx.branch() if current changeset is the tip of that branch
- "inbranch" has ctx.branch() if current changeset is _not_ the tip of that
branch and the branch is not "default"
- "branch" aka "changesetbranch" has ctx.branch() if the branch is not
"default"
The majority of cases (7 vs 2 + /graph) in paper theme used only option 3,
which meant that "default" was never displayed. But other parts of the theme
disagreed with this and used option 1 and option 2 together. For example, the
default view (log) displays "default" on the branch tip (can be seen right
about now on m-s.o/repo/hg), but it disappears when you click on the commit.
Also, using option 3 alone meant that there was no way to tell if a changeset
is the tip of its branch or not (it was always assumed that it's not, see how
some css classes change from "branchname" to the correct "branchhead" in tests)
-- so the two different css styles that exist in paper just for this were
underused.
I think this patch improves the situation, even though it changes the old (even
if inconsistent) behavior. The new behavior matches that of gitweb and
monoblue.
I'd like to call the function from an extension, passing both "strip"
and "prefix", but it currently only accepts "strip". The only in-tree
caller seems to be mq.py, which doesn't even pass "strip".
Differential Revision: https://phab.mercurial-scm.org/D1413
Less duplication and it's also easier to add extra "tags" everywhere at once.
These aren't tags as defined `hg help glossary` (hence the quotes), they are
simply called that. They include branch name (in different styles if changeset
is a head of that branch or not), (actual) tags and bookmarks. Good candidates
to add to this list would be changeset phase and obsoletion status.
.. feature::
Let 'hg rebase' avoid content-divergence by skipping obsolete
changesets (and their descendants) when they are present in the rebase
set along with one of their successors but none of their successors is
in destination.
In the following example, when trying to rebase 3:: onto 2, the rebase
will abort with "this rebase will cause divergence from: 4":
o 7 f
|
| o 6 e
| |
| o 5 d'
| |
x | 4 d (rewritten as 5)
|/
o 3 c
|
| o 2 x
| |
o | 1 b
|/
o 0 a
By excluding obsolete changesets without a successor in destination (4
in the example above) and their descendants, we make rebase work in this
case, thus giving:
o 11 e
|
o 10 d'
|
o 9 c
|
o 8 b
|
| o 7 f
| |
| | x 6 e (rewritten using rebase as 11)
| | |
| | x 5 d' (rewritten using rebase as 10)
| | |
| x | 4 d
| |/
| x 3 c (rewritten using rebase as 9)
| |
o | 2 x
| |
| x 1 b (rewritten using rebase as 8)
|/
o 0 a
where branch 4:: is left behind while branch 5:: is rebased as expected.
The rationale is that users may not be interested in rebasing orphan
changesets when specifying a rebase set that include them but would
still want "stable" ones to be rebased. Currently, the user is suggested
to allow divergence (but probably does not want it) or they must specify
a rebase set excluding problematic changesets (which might be a bit
cumbersome). The approach proposed here corresponds to "Option 2" in
https://www.mercurial-scm.org/wiki/CEDRebase.
We extend _computeobsoletenotrebased() so that it also return a set of
obsolete changesets in rebase set without a successor in destination but
with at least one successor in rebase set. This
'obsoletewithoutsuccessorindestination' is then stored as an attribute
of rebaseruntime and used in _performrebasesubset() to:
* filter out descendants of these changesets from the revisions to
rebase;
* issue a message about these revisions being skipped.
This only occurs if 'evolution.allowdivergence' option is off and
'rebaseskipobsolete' is on.
It is a bit wonky to assign the same object to multiple
attributes and then possibly overwrite them later.
Refactor the code to use a local variable and defer attribute
assignment until the final values are ready.
This required passing the bundle instance to _handlebundle2part().
The only use of this method I could find is Facebook's
treemanifest extension. Since it is a private method, I don't
think it warrants an API callout.
Differential Revision: https://phab.mercurial-scm.org/D1378
These attributes are implementation details and shouldn't be
exposed outside the class.
.. api::
bundlerepo.bundlerepository.bundle and
bundlerepo.bundlerepository.bundlefile are now prefixed with an
underscore.
Differential Revision: https://phab.mercurial-scm.org/D1377
exchange.readbundle() can return a type that represents a stream
clone bundle. Explicitly handle the bundle1 type and raise a
reasonable error message for unhandled bundle types.
Differential Revision: https://phab.mercurial-scm.org/D1376
It looks like the refactor in 0883a2ece555 attempted to establish
this method argument but failed to use it. My editor caught it.
Differential Revision: https://phab.mercurial-scm.org/D1373
My editor was complaining about mismatches between method
signatures.
For methods that are implemented, we change arguments to match
the base. For those that aren't, we use variable arguments
because it shouldn't matter.
Differential Revision: https://phab.mercurial-scm.org/D1372
Constants make code easier to read than magic numbers.
I also threw in an explicit argument in a caller to further
increase code comprehension.
Differential Revision: https://phab.mercurial-scm.org/D1370
This is a short topic to explain how command-line flags can be specified.
Some users have been confused by hg offerring different flag syntax than some
other libraries, so it'd be nice to point them to this rather than explaining
it every time.
Differential Revision: https://phab.mercurial-scm.org/D1270
The keys of keyword arguments must be str on Python 3 which is unicode. This
patch make sure we pass keyword arguments with keys are str everywhere in this
file and access the keys depending on whether they are bytes or str.
This patch uses pycompat.{byteskwargs|strkwargs} and somewhere it also added r''
to prevent transformer from adding a b'' over there.
Differential Revision: https://phab.mercurial-scm.org/D974
Everything is pretty self-explanatory except the last hunk, where jshint
complains: "Misleading line break before '||'; readers may interpret this as an
expression boundary."
There is a tweakable called "laxbreak" that allows line breaks before
operators, but I think it's fine to simply join this one line and avoid extra
config for now (we can cook up and add a sensible .jshintrc later).
The internal representation of bookmark value is binary. The fact we stored
'hex' was an implementation detail from using pushkey.
We move the values in 'pullop.remotebookmarks' to binary before adding a way to
exchange bookmarks not based on pushkey.
These new colors and styles are already used in the tooltip that gets shown
when user hovers over line numbers on annotate page. The old styles, replaced
in this patch, look completely unrelated to gitweb or any other hgweb theme.
These new colors and styles are already used in the tooltip that gets shown
when user hovers over line numbers on annotate page. The old styles, replaced
in this patch, look completely unrelated to paper or any other hgweb theme.
The dirstate typically tries to keep the nonnormalset and otherparentset
up-to-date when making changes to the dirstate. In the case of files marked
normallookup, however, it erroneously removes the file from the nonnormalset,
after _addpath had just added it.
This doesn't seem to matter at the moment, as nothing relies on the
nonnormalset being correct at this point, however a future re-implementations
of the dirstate map will require this to be kept up-to-date correctly.
Differential Revision: https://phab.mercurial-scm.org/D1339
dirstatemap.clear should remove all record of the files in the map. This
includes removing caches of values derived from these.
Differential Revision: https://phab.mercurial-scm.org/D1338
This utility function allows clearing of the cached value set up
@propertycache, if there is one.
Differential Revision: https://phab.mercurial-scm.org/D1337
This is fixing quadratic behavior, which is probably not noticeable in the
common case, but if a very large directory gets added here, it can get pretty
bad. This was noticed because we had some pushes that spent >25s in changegroup
generation calling min() here, according to profiling.
The original reasoning for min() being used in 1d71430e1d28 was that, at that
point in the series, we were adding almost everything to tmfnodes during the
first iteration through the loop , so we needed to avoid sending child
directories before parents. Later changes made it so that the child directories
were added only when we visited the parent directory (not all of them on the
first iteration), so this is no longer necessary - there won't be any child
directories in tmfnodes before the parents have been sent.
This does mean that the manifests are now exchanged unordered, whereas
previously we would essentially do [a, b, b/c, b/c/d, e], we now can send a, b,
and e in any order; b/c must still follow b, and b/c/d must still follow b/c.
Differential Revision: https://phab.mercurial-scm.org/D1351
With our treemanifest logic, the manifests are no longer transported as part of
the changegroup and are no longer stored in a revlog. This means the
self.manifestlog line in bundlerepo.filestart no longer calls
_constructmanifest, and therefore does not consume the manifest portion of the
changegroup, which means filestart is not populated and we result in an infinite
loop.
The fix is to make filestart aware that self.manifestlog might not consume the
changegroup part, and consume it manually if necessary.
There's currently no way to test this in core, but our treemanifest extension
has tests to cover this.
Differential Revision: https://phab.mercurial-scm.org/D1329
When origbackuppath is set, when looking to see if a file we are backing up
conflicts with a directory in the origbackuppath, we incorrectly match on
symlinks to directories. This means we try to call vfs.rmtree on the
symlink, which fails.
Differential Revision: https://phab.mercurial-scm.org/D1311
If origbackups are in use, a symlink to a valid directory is backed up, and an
update is made that attempts to backup a file or link over that symlink, we
abort with a bad error message instead of successfully updating.
Differential Revision: https://phab.mercurial-scm.org/D1310
We change subrepos.allowed from a list of allowed subrepo types to
a combination of a master switch and per-type boolean flag.
If the master switch is set, subrepos can be disabled wholesale.
If subrepos are globally enabled, then per-type options are
consulted. Mercurial repos are enabled by default. Everything else
is disabled by default.
These config items control share behavior that is implemented in core.
Since the functionality is implemented in core, extensions may
leverage it.
Mozilla has one such extension. And, it needs to access share.pool.
Before this patch, a devel warning regarding accessing an unregistered
config option would be issued unless the share extension were loaded.
Moving the registration of the config options to core fixes this.
We have a security issue with git subrepos. I'm not sure if svn subrepo is
vulnerable, but it seems not 100% safe to allow writing arbitrary data into
a metadata directory. So for now, only hg subrepo is enabled by default.
Maybe we should improve the help to describe why git/svn subrepos are
disabled.
This allows us to minimize the behavior change introduced by the next patch.
I have no idea which config style is preferred in UX POV, but I decided to
get things done.
a) list: 'allowed = hg, git, svn'
b) sub option: 'allowed.hg = True' or 'allowed:hg = True'
c) per-type action: 'hg = allow', 'git = abort'
This is an alternative workaround for the issue5730.
Perhaps this is the simplest way of disabling subrepo operations. It does
nothing clever, but just aborts if Mercurial starts accessing to a subrepo.
I think Greg's patch is more useful since it allows us to at least check
out the parent repository. However, that would be confusing if the default
is flipped to checkout=False and subrepos are silently ignored.
I don't like the config name 'allowed', but I couldn't get any better name.
Previously, if there were unresolved files and the CWD drive was different from
the repo drive, `hg status -v` would page the normal status, followed by the
exception header. A stacktrace was waiting when the pager exited. The
underlying cause was the same as 12441ef4442f.
Unfortunately, I don't see any reasonable way to write a test this [1].
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/107401.html
This is a followup to 12441ef4442f. Since there's no way to ensure that more
drive letters than C: exist, this seems like the only way to test it. This is
enough to catch the 12441ef4442f scenario, as well as CWD outside of the repo
when the path isn't prefixed with path/to/repo.
