This passed an empty list to filerevert() if '--all' was specified, otherwise
the set of modified files. But then filerevert() immediately switched this and
reinitialized 'pats' to an empty list if '--all' was *not* specified.
Since the point of --dry-run is to show what will happen, the output with and
without it should agree. And since revert wasn't being called on subrepos with
--dry-run before, revert in the subrepo had to be defanged in this case.
Previously, when a largefile is forgotten and then reverted, a warning was
issued:
$ hg revert -R subrepo subrepo/large.txt
file not managed: subrepo/large.txt (glob)
This was purely cosmetic as the file itself actually was reverted.
The problem was even with all of the matcher patching, the largefile pattern
given on the command line wasn't converted to a standin because the standin was
neither in ctx nor wctx. This causes the named largefile to be added to the
'names' dict in cmdutil.revert() in the repo walk at line 2550. The warning was
printed out when the 'names' dict is iterated, because the file was specified
exactly.
Since core revert recurses into subrepos and largefiles only overrides the
revert method in commands.py, it doesn't work properly when reverting a subrepo.
However, it still will recurse into the subrepo and call the installed matcher
method, so lfdirstate is reopened for the current repo level to prevent any new
problems.
Previously, the histedit state object was being recreated during continue/abort.
This meant that the locks that were held on the original state object were not
available to actions, which meant actions could not release the lock on the
repository (like an 'exec' action would need to do).
This affected our internal extension that added the 'exec' action.
Elements in map files work slightly different from regular python strings, so
escaping single quotes is not necessary. It is also demonstrated by the very
same lines: '(current diff)'.
I should've made this in 3468fd599ef4, but here we go.
It was introduced at 1e92106a20bc to warn that "hg resolve" did nothing
meaningful. The warning seems not good for "hg resolve -l" because it is
rather like "hg status" or "hg files".
Mercurial uses a synopsis string and the docstring of a command for the
command's help output. Today there is no way for an extension that adds
functionality to a command to extend either of these help strings.
This patch enables appending to both the doctring and the synopsis, and adds
a test for this functionality. Example usage is shown in the test and is also
described in the docstring of extensions.wrapcommand().
A delta against a censored revision is either received through exchange and
written blindly to a revlog, or it is created by the revlog itself. This
change ensures the latter process creates deltas which fully replace all
data in a censored base using a single patch operation.
Recipients of a delta against a censored base will verify that the delta is in
this full-replace format. Other recipients will use the delta as normal.
For background and broader design of the censorship feature, see:
http://mercurial.selenic.com/wiki/CensorPlan
When a delta received through exchange is added to a revlog, it will very
often be expanded to a full text by applying the delta to its base. If
that delta is of a particular form, we can avoid decoding the base revision.
This avoids an exception if the base revision is censored.
For background and broader design of the censorship feature, see:
http://mercurial.selenic.com/wiki/CensorPlan
debugsetparents is a debug command and does not provide the same
guarantees as non-debug commands do. In particular, when the user sets
a different parent, any clean files will remain clean in the dirstate
even though the new parent might have a different version of the file
(so it should appear modified compared to the new parent). Let's
instead achieve the same effect by updating to the new parent and
reverting the contents back to what they were.
This fix can be tested by passing '--config
debug.dirstate.delaywrite=2' to the 'hg update' command in the
beforemerge().
To ensure interoperability when clones disagree about which file nodes are
censored, a restriction is made on deltas based on censored nodes. Any such
delta must replace the full text of the base in a single patch.
If the recipient of a delta considers the base to be censored and the delta
is not in the expected form, the recipient must reject it, as it can't know
if the source has also censored the base.
For background and broader design of the censorship feature, see:
http://mercurial.selenic.com/wiki/CensorPlan
This helper will be used initially for censor-aware delta generation. Deltas
which replace the full contents of the base revision are guaranteed to apply
correctly regardless of whether the delta recipient has censored the base.
For background and broader design of the censorship feature, see:
http://mercurial.selenic.com/wiki/CensorPlan
The iscensored method will be used by the exchange layer to reject
nonconforming deltas involving censored revisions (and to produce
conforming deltas).
For background and broader design of the censorship feature, see:
http://mercurial.selenic.com/wiki/CensorPlan
To ensure delta compatibility, when a revision is censored, it is
padded to match the original data in size. The previous check does
not allow for padding because it was added before padding was found
to be a requirement.
For more background and design of the censorship feature, see:
mercurial.selenic.com/wiki/CensorPlan
This change is intended to avoid exposing the implementation detail to
callers. I'm going to extend fullreposet to support "null" revision, so
these mfunc calls will have to use fullreposet() instead of spanset().
If a commit and a followup tag commit are pruned, there are no references to it
in any non obsolete version of .hgtags. Without this change however, the next
time a tag is added to another branch, the obsolete references are appended in
.hgtags before the new entries for the current tag command.
The annotation to unfilter localrepo._tag() has been around since 3da49fd631fb.
The log message for it mentions computing the tag cache though, so I'm not sure
if this was misplaced? It looks like branchmap was aware of filtering then, and
now tracks a cache per view.
Currently, if the node no longer exists, the state object fails to load
and pukes with an exception. Changing the state object to only store the
node allows callers to handle these cases. For instance, in
bootstrapcontinue we can now detect that the node doesn't exist and exit
gracefully.
The alternative is to have the state object store something like None
when the node doesn't exist, but then outside callers won't be able to
access the old node for recovery (unless we store both the node and the
ctx, but why bother).
More importantly it allows us to detect this case when doing hg histedit
--abort. Currently this situation results in both --continue and
--abort being broken and the user has to rm .hg/histedit-state to unwedge
their repo.
(description by Durham Goode)
During histedit we don't want user to do any operation resulting in
stripping nodes needed to continue history editing. This patch
wraps the strip function to detect such situations.
The code that identifies copies/renames, as well as the filenames
before and after, is now isolated and we can extract it to a function
so it can be overridden by extensions (in particular the narrow clone
extension).
There is not much left of the first block "if opts.git or losedatafn"
block now. The next patch will move the call to getfilectx() out of
that block. We will then be using the defined-ness of 'f1' to tell
whether the file existed in ctx1 (and under what name). We will need
this information whether or not opts.git or losedatafn was set, so
just remove that guard. The only operation in the block that is not
cheap is the call to getfilectx(), but that has an extra 'if opts.git'
guard already.
--ignore-space-change proves that only 'if opts.git or losedatafn:'
was removed.
f1 and f2 are currently set always set to some filename, even for
added or deleted files. Let's instead set them to None to indicate
that one side of the diff doesn't exist. This lets us use the filename
variables instead of the content variables and simplify a bit since
the empty string is not a valid filename. More importantly, it paves
the way for further simplifications.
Merge tools were being double documented in help system output due
to functions being defined under multiple names in the merge tools
dictionary.
Establish a new dictionary for just the tools to document and
use it from the help system so we don't get double output.
Double documentation likely plagues other auto-documented items
as well. It might be a good idea to eventually compare function
instances to filter out duplicate entries from dictionaries
passed to ``makeitemsdoc``. However, without an easy way to break
ties, this may result in some functions being advertised over
their modern equivalents. This would be a noble patch series.
But it isn't one this author is willing to tackle at this time.
When using docstrings for documenting symbols such as revsets,
templates, or hgweb commands, documentation likely has leading
whitespace corresponding to the indentation from the Python source
file.
Up until this point, the help system stripped all leading and
trailing whitespace and replaced it with 2 spaces of leading
whitespace. There were a few bad side-effects. First, sections
could not be used in docstrings because they would be indented
and the rst parser would fail to parse them as sections. Also,
any rst elements that required indentation would lose their
indentation, again causing them to be parsed and rendered
incorrectly.
In this patch, we teach the topic symbols system how to dedent
text properly. I argue this mode should be enabled by default.
However, I stopped short of changing that because it would cause
a lot of documentation reformatting to occur. I'm not sure if
people are relying on or wanting indentation. So, dedenting has
only been turned on for hgweb symbols. This decision should be
scrutinized.
