Before this patch revert interactive mode unconditionally forgets
added files. This patch fixes this by asking user if he wants
to forget added file. If user doesn't want to forget given file,
it is added to matcher_opts exclude list, to not reviewing it
later with other modified files.
Clone bundles require a well-defined string to specify the type of
bundle that is listed so clients can filter compatible file types. The
`hg bundle` command and cmdutil.parsebundletype() already establish the
beginnings of a bundle specification format.
As part of formalizing this format specification so it can be used by
clone bundles, we move the specification parsing bits verbatim to
exchange.py, which is a more suitable place than cmdutil.py. A
subsequent patch will refactor this code to make it more appropriate as
a general API.
This can centralize the logic to write in-memory changes out correctly
according to transaction activity into dirstate.
Passing 'repo' object to newly added functions is needed to examine
current transaction activity in subsequent patches, because 'dirstate'
itself doesn't have direct reference to it.
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
There is no user of 'cmdutil.tryimportone()' other than
'commands.import_()', which can restore dirstate at failure of
applying patches by transaction or dirstateguard.
Therefore, it is reasonable to stop 'tryimportone()' from using
redundant 'dirstateguard', even though it changes behavior of
'tryimportone()'.
After this patch, 3rd party extensions should use 'dirstateguard' or
so explicitly, if they want to restore dirstate at failure of
importing a patch.
Previous patch made dirstate changes in a transaction scope "all or
nothing". Therefore, 'dirstateguard' is meaningless, if its scope is
as same as one of the related transaction.
This patch removes such meaningless 'dirstateguard' usage.
As we have a way for extension to add more header, we need a way for them to
actually process them. We add a basic hook point to do extra work after the
import have been committed.
As we have a way for extension to add more header, we need a way for them to
actually process them. We add a basic hook points to alter the changeset
(especially extra) before we commit. There would be more to do for a full
featured hooking, but this currently fit my needs.
The final goal here is to be able to parse, return and process arbitrary data
from patch. This mirror the recently added ability to add arbitrary data to
patch headers.
The first step is to return something more flexible, so we return a dict without
changing any other logic.
Extensions currently have no easy way to add data to exported
patch. This is now fixed using a generic mechanism in the same fashion
used by bundle2. Tests are coming in the next changeset with its first
user.
As bundle1 does not support generaldelta, this would mean recomputing delta at
bundle time. This is similar to what we do for strip and shelve and was tracked
as issue4865.
We had some basic undocumented support for uncompressed bundle2 support. We now
have an official extensible syntax to specify both format type and compression
(eg: bzip2-v2).
In practice, this changeset introduce the 'v1' and 'v2' identifier to make it
possible to combine format and compression. The default format is still 'v1'.
We'll care about picking 'v1' or 'v2' in regard with general delta in the next
changesets.
We are going to introduce significant extensions of the bundle parsing code to
support creation of bundle2 through the bundle command. As an early step, we
extract the logic in its own function.
It isn't cool, but we can peek at ui flag via repo.ui. So, it is possible
to implement showparents() in templatekw, and therefore we can eliminate the
dockeywords hack.
Before this, if a localizer/localization included a multiline
message, and didn't prefix the intermediate lines with 'HG: ',
then the line would be a candidate for inclusion in the commit
message -- which isn't ideal.
Previously cmdutil.add would call wctx.walk(), which under the hood calls
dirstate.walk with full=True. This means it returns all of the clean files
(which we don't need when computing the add set), as well as the unclean files.
This results in 1) a lot more work being done and 2) this code path
circumventing the hgwatchman extension, resulting in worse performance in
hgwatchman environments ('hg add .' went from 9s to 1.8s).
Interactive committing under non-interactive mode shows command
suggestion, but sometimes it is meaningless.
command suggestion usability
------------ ---------- -----------
record commit
commit -i commit meaningless
qrecord qnew
qnew -i qnew meaningless
qrefersh -i qrefresh meaningless
shelve -i commit incorrect
------------ ---------- -----------
This patch allows callers of 'cmdutil.dorecord()' to omit meaningless
suggestion by passing None or so for 'cmdsuggest' argument of it.
This is a preparation for subsequent patches, which fix each
suggestion issues above.
Because flush() is the function to write data buffered by show(ctx),
flush(ctx) is more consistent than flush(rev). This makes sure that
buffered header and hunk are always keyed by ctx.rev().
This patch will allow us to give an integer to the wdir while keeping
wctx.rev() -> None.
Because we want to eliminate "if"s in the default template, it makes sense to
display wdirrev/wdirnode values for now. wdir() is still experimental, so the
output of "log -r'wdir()'" may change in future.
To detect change of a file without redundant comparison of file
content, dirstate recognizes a file as certainly clean, if:
(1) it is already known as "normal",
(2) dirstate entry for it has valid (= not "-1") timestamp, and
(3) mode, size and timestamp of it on the filesystem are as same as
ones expected in dirstate
This works as expected in many cases, but doesn't in the corner case
that changing a file keeps mode, size and timestamp of it on the
filesystem.
The timetable below shows steps in one of typical such situations:
---- ----------------------------------- ----------------
timestamp of "f"
----------------
dirstate file-
time action mem file system
---- ----------------------------------- ---- ----- -----
N *** ***
- change "f" N
- execute 'hg commit -i'
- backup "f" with timestamp N
- revert "f" by 'merge.update()' N
with 'partially'
- apply selected hunks N
by 'patch.patch()'
- 'repo.commit()'
- 'dirstate.normal("f")' N
N+1
- 'dirstate.write()' N N
- restore "f" N+1
- restore timestamp of "f" N
- 'hg status' shows "f" as "clean" N N N
---- ----------------------------------- ---- ----- -----
The most important point is that 'dirstate.write()' is executed at N+1
or later. This causes writing dirstate timestamp N of "f" out
successfully. If it is executed at N, 'parsers.pack_dirstate()'
replaces timestamp N with "-1" before actual writing dirstate out.
This issue can occur when 'hg commit -i' satisfies conditions below:
- the file is committed partially, and
- mode and size of the file aren't changed before and after committing
The root cause of this issue is that (maybe partially changed) files
are restored with original timestamp but dirstate isn't updated for
them.
To detect changes of files correctly, this patch applies
'dirstate.normallookup()' on restored files. Status check is needed
before 'dirstate.normallookup()', because status other than "n(ormal)"
should be kept at failure of committing.
This patch doesn't examine whether each files are committed fully or
partially, because interactive hunk selection makes it difficult.
After this change, timetable is changed as below:
---- ----------------------------------- ----------------
timestamp of "f"
----------------
dirstate file-
time action mem file system
---- ----------------------------------- ---- ----- -----
N *** ***
- change "f" N
- execute 'hg commit -i'
- backup "f" with timestamp N
- revert "f" by 'merge.update()' N
with 'partially'
- apply selected hunks N
by 'patch.internalpatch()'
- 'repo.commit()'
- 'dirstate.normal("f")' N
N+1
- 'dirstate.write()' N N
- restore "f" N+1
- restore timestamp of "f" N
----------------------------------- ---- ----- -----
- normallookup("f") -1
- release wlock
- 'dirstate.write()' -1 -1 N
----------------------------------- ---- ----- -----
- 'hg status' shows "f" as "clean" -1 -1 N
---- ----------------------------------- ---- ----- -----
To reproduce this issue in tests certainly, this patch emulates some
timing critical actions as below:
- change "f" at N
'touch -t 200001010000' before command invocation changes mtime of
"f" to "2000-01-01 00:00" (= N).
- apply selected hunks at N
'patch.internalpatch()' with 'fakepatchtime.py' explicitly changes
mtime of patched files to "2000-01-01 00:00" (= N).
- 'dirstate.write()' at N+1 (or "not at N")
'pack_dirstate()' uses actual timestamp at runtime as "now", and
it should be different from the "2000-01-01 00:00" of "f".
BTW, in 'test-commit-interactive.t', files are sometimes treated as
modified , even though they are just committed fully via 'hg commit
-i' and 'hg diff' shows nothing for them.
Enabling win32text causes EOL style mismatching below:
- files are changed in LF style EOL
=> files restored after committing uses LF style EOL (1)
- 'merge.update()' reverts files in CRLF style EOL
- 'patch.internalpatch()' changes files in CRLF style EOL
=> 'dirstate.normal()' via 'repo.commit()' uses the size of files
in CRLF style EOL (2)
Therefore, fully committed files are treated as "modified", because
'lstat()' returns size of (1) restored files in LF style EOL, but
dirstate expects size of (2) committed files in CRLF style EOL.
After this patch, 'dirstate.normallookup()' on committed files forces
subsequent 'hg status' to examine changes exactly, and fully committed
files are treated as clean as expected.
This is reason why this patch also does:
- add some 'hg status' checking status of fully committed files
- clear win32text configuration before size/timestamp sensitive examination
Before this patch, 'recordfunc()' for interactive hunk selection does
below outside wlock scope at 'hg commit -i' and so on:
- backup files, which may be partially changed
- apply selected hunks on files
- restore files from backup-ed ones
These should be executed inside wlock scope for consistency.
To put them into wlock scope without largely changing indents in
'recordfunc()', this patch adds another wrapper function.
This patch is also a preparation for subsequent patch fixing the issue
to correctly recognize partially committed files as "modified".
Explicit 'dirstate.normallookup()' invocation in 'revert()' is useless
now, because previous patch fixed the relevant issue by writing
in-memory dirstate changes out at the end of dirty check.
'dirstate.normallookup()' invocation was introduced by 1a735e934681 to
avoid occasional test failure (see issue4583 for detail). This is
partial backout of it (added tests are still left).
Because we defined the working-directory revision is INT_MAX, it makes sense
that "hg log -r 'wdir()'" displays the "parent:" field. This is the same for
two revisions that are semantically contiguous but the intermediate revisions
are hidden.
The value is used at multiple points in the function. Retrieving the
value in the middle of the transaction scope gives the false
impression that it has a single user. We move it at the start of the
function to clarify this.
There was code to move the bookmarks around both in the 'cmdutil' help and in
the main 'commit' function. We kill the 'commit' version as it is performed
outside the transaction.
The debug note is moved into cmdutil.
We have code moving bookmarks from the old changeset to the new one within the
transaction scope. Yet this code was still writing to disk instead of
handing the change to the transaction. This changeset fixes this.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
After the discussion on the list about hg revert -i, it seems like we are
satisfied with what we called proposition 2. It shows the changes to revert in
the same direction as hg diff. This patch makes it the default option.
It changes all the + in - and vice versa in the tests for revert -i.
We want to share this function between formatter and cmdutils. It
doesn't belong in templater because it imports knowledge of ui layers
that shouldn't be there. We'd prefer cmdutil to layer on the formatter
rather than vice-versa. Since the formatter is the handler for -T
options for all non-log commands, let's move the helper there. We
leave the bits specific to the old --style option behind.
The previous code didn't restore the original method, but it looks like the
worst that would happen is junk added to a list that had already been processed
by previous subrepo invocation(s).
The previous code didn't restore the original method, but it looks like the
worst that would happen is junk added to a list that had already been processed
by previous subrepo invocation(s).
We had a discussion on the list about the interactive ui for revert. This patch
adds a flag to allow people to test the second alternative (referred to as
proposition 2 on the mailing list). It effectively inverts the signs in the
This patch is part of a series of patches to change the recording ui to reflect
the operation currently running (commit, shelve, revert ...).
This patch adds a new argument to the recording function to reflect in the UI
what operation we are running.
Before this patch: editing hunks of newly added file when performing a revert
--interactive had no effect: the edits were discarded.
After this patch, the edits are taken into account.
This allows us to use existing code to detect files that are newly added and
modified. In turn, this allows us to make revert --interactive support
editing newly added and modified files.
It should be possible to debug the submanifest revlogs without having
to know where they are stored (in .hg/store/meta/), so let's add a
--dir option for this purpose.
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.
Previously import used force=partial to allow empty commits to be made. Let's
switch it to using the new ui.allowemptycommit option. Tests says we can drop
the 'force' argument in the processs.
To fix the issue that the recent (in memory) dirstate isn't visible to
external process (e.g. "precommit" hook), a subsequent patch makes
"localrepository.commit()" invoke "dirstate.write()" in it.
This change will make "beginparentchange()" and "endparentchange()" on
dirstate in "cmdutil.tryimportone()" meaningless, because:
- "dirstate.write()" writes changed data into ".hg/dirstate", but
- aborting between "beginparentchange()" and "endparentchange()"
doesn't cause any restoring ".hg/dirstate"
it just discards changes in memory.
This patch uses "dirstateguard" instead of "beginparentchange()" and
"endparentchange()" in "cmdutil.tryimportone()" to restore
".hg/dirstate" during a failure even if "dirstate.write()" is executed
before a failure.
This patch uses "lockmod.release(dsguard)" instead of
"dsguard.release()", because processing may be aborted before
assignment to "dsguard" , and the "if dsguard" examination for safety is
redundant.
Before this patch, "cmdutil.amend()" uses "dirstate.invalidate()" as a
kind of "restore .hg/dirstate to the original status" during a failure.
But it just discards changes in memory, and doesn't actually restore
".hg/dirstate". Then, it can't work as expected, if "dirstate.write()"
is executed while processing.
This patch uses "dirstateguard" instead of "dirstate.invalidate()" to
restore ".hg/dirstate" at failure even if "dirstate.write()" is
executed before failure.
This is a part of preparations to fix the issue that the recent (in
memory) dirstate isn't visible to external process (e.g. "precommit"
hook).
Before this patch, after "dirstate.write()" execution, there was no way to
restore dirstate to the original status before "dirstate.write()".
In some code paths, "dirstate.invalidate()" is used as a kind of "restore
.hg/dirstate to the original status", but it just avoids writing changes in
memory out, and doesn't actually restore the ".hg/dirstate" file.
To fix the issue that the recent (in memory) dirstate isn't visible to external
processes (e.g. "precommit" hooks), "dirstate.write()" should be invoked before
invocation of external processes. But at the same time, ".hg/dirstate" should be
restored to its content before "dirstate.write()" during an unexpected failure
in some cases.
This patch adds the class "dirstateguard" to easily restore ".hg/dirstate"
during unexpected failures. Typical usecase of it is:
# (1) build dirstate up
....
# (2) write dirstate out, and backup ".hg/dirstate"
dsguard = dirstateguard(repo, 'scopename')
try:
# (3) execute somethig to do:
# this may imply making some additional changes on dirstate
....
# (4) unlink backed-up dirstate file at the end of dsguard scope
dsguard.close()
finally:
# (5) if execution is aborted before "dsguard.close()",
# ".hg/dirstate" is restored from the backup
dsguard.release()
For this kind of issue, an "extending transaction" approach (in
https://titanpad.com/mercurial32-sprint) seems to not be suitable, because:
- transaction nesting occurs in some cases (e.g. "shelve => rebase"), and
- "dirstate" may be already modified since the beginning of OUTER
transaction scope, then
- dirstate should be backed up into the file other than
"dirstate.journal" at the beginning of INNER transaction scope, but
- such alternative backup files are useless for transaction itself,
and increases complication of its implementation
"transaction" and "dirstateguard" differ from each other also in "what
it should do for .hg/dirstate" in cases other than success.
============== ======= ======== =============
type success fail "hg rollback"
============== ======= ======== =============
transaction keep keep restore
dirstateguard keep restore (not implied)
============== ======= ======== =============
Some collaboration between transaction and dirstate will probably be introduced
in the future. But this layer is needed in all cases.
Previously this function accepted two optional parameters that were unused by
any callers and complicated the function.
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.
This speeds up 'hg remove python/README' on the Firefox repo from
2.479s to 0.664s with lazily loaded treemanifests (which is not yet in
core) and has no measurable effect on flat manifests.
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.
In my latest change on record (edit newly added file), I forgot the
repo.wjoin() so that record was not computing the paths properly to delete
the backups and was crashing.
This wrapping seems meaningless, because:
- there is no "_()" invocation to prepare for extracting phase names
to be translated
"make update-pot" doesn't extract msgids for phase names
- phase names are kine of reserved keywords like as branch name "default"
This regressed in 39be809de631, in what looks like an unrelated change.
It seems sufficient to pass 'ignoremissing=True', but the restored try/except
has been there for six years since 3f24f7324cd8, so this seems safer for now.
Note that renaming directories in the filename doesn't appear to work- not sure
if this would end up throwing a different type of error when that is fixed.
I tried to fix this issue in the past and had to revert the fix. This is a
second attempt without the regression we found with the first one.
record defines special headers (of file) as headers whose hunk are not shown
to the user for editing, they are used to represent deleted, moved and new
files. Since we want to authorize editing the patch of newly added file we
make the newly added file with some content not special anymore. This entails
that we have to save their content before applying the backup to be able to
revert it if the patch does not apply properly.
We reintroduce the test showing that newly added files can be edited and that
their content is shown to the user.
Before this patch, reverting a file to the revision other than the
parent doesn't update dirstate. This seems to expect that timestamp
and/or size will be changed by reverting.
But if (1) dirstate of file "f" is filled with timestamp before
reverting and (2) size and timestamp of file "f" isn't changed at
reverting, file "f" is recognized as CLEAN unexpectedly.
This patch applies "dirstate.normallookup()" on reverted file, if size
isn't changed.
Making "localrepository.wwrite()" return length of written data is
needed to avoid additional (and redundant) "lstat(2)" on the reverted
file. "filectx.size()" can't be used to know it, because data may be
decoded at being written out.
BTW, interactive reverting may cause similar problem, too. But this
patch doesn't focus on fixing it, because (1) interactive (maybe slow)
reverting changes one (or both) of size/timestamp of reverted files in
many usecases, and (2) changes to fix it seems not suitable for stable
branch.
The goal of 'hg revert --interactive' is usually to keep some change in the
revert file, so the files -must-not- be marked as clean. We want the status
logic to do its usual job here.
For unclear reasons (probably timing related), I was unable to build an automated
test that reproduced issue4592 but manual testing shows this is fixed.
An upcoming commit requires that match.py be able to call scmutil.dirs(), but
when match.py imports scmutil, a dependency cycle is created. This commit
avoids the cycle by moving dirs() and its related finddirs() function from
scmutil to util, which match.py already depends on.
Unlike changeset_printer, it does not hide the manifest field because JSON
output will be parsed by machine where explicit "null" will be more useful
than nothing.
Previously, specifying a file name but not matching the dirstate case yielded
the following, even though the file was actually removed:
$ hg forget capsdir1/capsdir/abc.txt
not removing capsdir\a.txt: file is already untracked
removing CapsDir\A.txt
[1]
This change doesn't appear to cause any extra filesystem accesses, even if a
nonexistant file is specified.
If a directory is specified without a case match, it is (and was previously)
still silently ignored.
In "commands.update()", "cmdutil.bailifchanged()" isn't used for
"abort if the working directory is dirty", because it forcibly
examines about merging in progress.
"workingctx.dirty()" used in "commands.update()" can't detect changes
of largefiles in the working directory without "repo.lfstatus = True"
wrapping. This is only reason of "commands.update()" wrapping by
largefiles extension.
On the other hand, "cmdutil.bailifchanged()" already wrapped by
largefiles extension can detect changes of largefiles.
This patch is a preparations for replacing "workingctx.dirty()" and
raising Abort in "commands.update()" by "cmdutil.bailifchanged()". It
can remove redundant "commands.update()" wrapping.
Reverting to a revision where the subrepo didn't exist will now abort, and
matching subrepos against the working directory is consistent with how filesets
are evaluated since dd1c701aad4d.
The list of subrepos to revert is currently based on the given --rev, so there
is currently no way for this to fail. Using the --rev context is wrong though,
because if the subrepo doesn't exist in --rev, it is skipped, so it won't be
changed. This change makes it so that the revert aborts, which is what happens
if a plain file is reverted to -1. Finding matches based on --rev is also
inconsistent with evaluating files against the working directory (dd1c701aad4d).
This change is made now, so as to not cause breakage when the context is
switched in an upcoming patch.
Before this change, amending a merge would lose the rename information for file
adding in the second parents and implicitly renamed into a new directory.
In case of the merge, we also look for directory rename data from the second
parent. This seems to fix the bug and does not show other issues from the test
suite.
Before this patch, "_()" is used incorrectly for "tag:" and
"bookmark:" fields. "changeset_printer()" looks up keys composed at
runtime, and it prevents "xgettext" command from getting strings to be
translated from source files.
Then, *.po files merged with updated "hg.pot" lose msgids for "tag:"
and "bookmark:".
This patch introduces "logfmt" information into "namespace" to show
l10n-ed messages "hg log" (or "changeset_printer()") correctly.
For similarity to other namespaces, this patch specifies "logfmt" for
"branches" namespace, even though it isn't needed (branch information
is handled in "changeset_printer()" specially).
To find related code paths out easily, this patch adds "i18n: column
positioning ..." comment to the line composing "logfmt" by default,
even though this line itself doesn't contain any strings to be
translated.
The prefetch logic came before the actual population of the actions collection,
so it was always being passed an empty action list. This fixes it by moving it
to after that logic.
The only consumer of this function at the moment is remotefilelog, and I
verified it works with this change.
This speeds up 'hg revert -r .^ --all --dry-run' on the Mozilla repo
from 4.081s to 0.826s. Note that 'hg revert -r .^ .' does not get any
faster, since '.' does not make match.always() True.
I can't think of a reason it would break anything, and if it does,
it's clearly not covered by tests.
The largefiles extensions needs to be able to pass --large, --normal and
--lfsize to subrepos via cmdutil.add() and hgsubrepo.add(). Rather than add
additional special purpose arguments, stop extracting the existing args from the
**opts passed to commands.add() and just pass them along.
It seems like a mistake to report a file as forgotten and rejected. The
forgotten list doesn't seem to be used by anything in core, so no test changes.
As the failing revert tests in test-fileset-generated.t show,
Revert currently creates one matcher for matching files in the working
copy and another matcher for matching files in the target
revision. The two matchers are created with different contexts, which
means filesets are evaluated differently. Then the union of the sets
of files matching the matchers in the two contexts are reverted. It
doesn't seem to make sense to use two different matchers; only the
context they're applied to should be different.
It seems very likely that the user wants the filesets to be evaluated
against the working directory, which the tests
test-fileset-generated.t also assume, so let's make it so.
I willingly admit that the largefiles code was modified by trial and
error (according to tests).
The only caveat here is that branches must be displayed first due to backwards
compatibility. The order of namespaces is defined to be the 'update' order
which, unfortunately, is not the same as log output order.
It's worth mentioning that the log output is still translated the same as
before since we are formating our strings the same way:
# i18n: column positioning for "hg log"
_("bookmark: %s\n") % bookmark
becomes
tname = _(("%s:" % ns.templatename).ljust(13) + "%s\n") % name
when name == 'bookmark'. The ljust(13) keeps the strings and whitespace equal.
Adding a new namespace is even easier now because the log output code doesn't
need to change. A future programmer would just need to add the string to the
corresponding .po file (which is the same as they would have had to do
previously).
Paths into the subrepo are not yet supported.
The need to use the workingctx in the subrepo will likely be used more in the
future, with the proposed working directory revset symbol. It is also needed
with archive, if that code is to be reused to support 'extdiff -S'.
Unfortunately, it doesn't seem possible to put the smarts in subrepo.subrepo(),
as it breaks various status and diff tests.
I opted not to pass the desired revision into the subrepo method explicitly,
because the only ones that do pass an explicit revision are methods like status
and diff, which actually operate on two contexts- the subrepo state and the
explicitly passed revision.
The class only depends on the 'repo' variable in the closure, so let's
move the class out of the function and make it explicit that that (the
repo) is all it needs.
Since "slowpath = match.anypats() or (match.files() and
opts.get('removed'))", we can simplify the condition "not slowpath and
not match.files()" to "not match.anypats() and not match.files()",
which is equivalent to "match.always()".
The _enabled bool has been replaced by obsolete.isenabled(...). This removes the
last instance of it so I can remove the _enabled flag entirely shortly.
"working directory" is the standard term, we should use it consistently.
But I didn't touch the hint, "run 'hg update' to get a working copy", because
"get a working directory" sounds a bit odd.
Although Python supports `X = Y if COND else Z`, this was only
introduced in Python 2.5. Since we have to support Python 2.4, it was
a very common thing to write instead `X = COND and Y or Z`, which is a
bit obscure at a glance. It requires some intricate knowledge of
Python to understand how to parse these one-liners.
We change instead all of these one-liners to 4-liners. This was
executed with the following perlism:
find -name "*.py" -exec perl -pi -e 's,(\s*)([\.\w]+) = \(?(\S+)\s+and\s+(\S*)\)?\s+or\s+(\S*)$,$1if $3:\n$1 $2 = $4\n$1else:\n$1 $2 = $5,' {} \;
I tweaked the following cases from the automatic Perl output:
prev = (parents and parents[0]) or nullid
port = (use_ssl and 443 or 80)
cwd = (pats and repo.getcwd()) or ''
rename = fctx and webutil.renamelink(fctx) or []
ctx = fctx and fctx or ctx
self.base = (mapfile and os.path.dirname(mapfile)) or ''
I also added some newlines wherever they seemd appropriate for readability
There are probably a few ersatz ternary operators still in the code
somewhere, lurking away from the power of a simple regex.
In plain `hg log` there is no indication that a commit closes a
branch. You can use hg log --debug, but this is too verbose. A simple
idea copied from thg and other graphical viewers is to display the
node for a closing-branch commit as a horizontal line.
I think this technically is a BC if we consider the graphlog to be
part of the stdout API, but I really can't imagine who the hell is
parsing the graphlog to determine information about commits.
The workingctx class was using dirstate.dirs() as it's implementation. The
sparse extension maintains a pruned down version of the dirstate, so this
resulted in the workingctx reporting an incorrect listing of directories
during merge calculations (it was detecting directory renames when it
shouldn't have).
The fix is to use the default implementation, which uses workingctx._manifest,
which unions the manifest with the dirstate to produce the correct overall
picture. This also produces more accurate output since it will no longer
return directories that have been entirely deleted in the dirstate.
Tests will be added to the sparse extension to detect regressions for this.
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.
If p1 is null, ':.' is translated as '0:null'. But rangeset can't handle null,
only revision 0 was visible. Because 'null' should not be listed implicitly,
"log --follow" (without -r) should be empty if p1 is null.
Test of "hg grep -f" is added for cmdutil.walkchangerevs().
This prepares for extracting common part from getgraphlogrevs() and
getlogrevs(). getlogrevs() does not handle empty repo specially.
When it was added at a98e985d1dd1, revs were build by old-style query, '.:0'.
So I think the purpose of "len(repo) > 0" was to handle the case of . = null.
Currently it isn't necessary for 'reverse(:.)', and it does not work if repo
is not empty but p1 is null.
$ hg up null
$ hg glog --follow -T '{rev}:{node|short}\n'
o 0:0a04b987be5a
The subsequent patch will fix this problem, so drops the wrong version for now.
jsonchangeset._show() was computing the reverse status of the current
changeset. As a result, added files were showing up as removed and
removed files were showing up as adds.
There were existing tests for this code and they were flat out wrong.
The log/graphlog revset was not producing stable results since it was
iterating over a dict. Now we sort before iterating to guarantee a fixed order.
This fixes some potential flakiness in the tests.
The revset created when -f was used with a slow path (for patterns and
directories) did not actually contain any logic to enforce follow. Instead it
was depending on the passed in subset to already be limited (which was limited
to :. but not ::.). This fixes it by adding a '& ::.' to any -f log revset.
hg log -f <file> is still broken, in that it can return results that aren't
actually ancestors of the current file, but fixing that has major perf
implications, so we'll deal with it later.
The full path is propagated to the original match object since this is often
used directly for printing a file name to the user. This is cleaner than
requiring each caller to join the prefix with the file name prior to calling it,
and will lead to not having to pass the prefix around separately. It is also
consistent with the bad() and abs() methods in terms of the required input. The
uipath() method now inherits this path building property.
There is no visible change in path style for rel() because it ultimately calls
util.pathto(), which returns an os.sep based path. (The previous os.path.join()
was violating the documented usage of util.pathto(), that its third parameter be
'/' separated.) The doctest needed to be normalized to '/' separators to avoid
test differences on Windows, now that a full path is returned for a short
filename.
The test changes are to drop globs that are no longer necessary when printing an
absolute file in a subrepo, as returned from match.uipath(). Previously when
os.path.join() was used to add the prefix, the absolute path to a file in a
subrepo was printed with a mix of '/' and '\'. The absolute path for a file not
in a subrepo, as returned from match.uipath(), is still purely '/' based.
This no longer needs to be explicitly passed because the subrepo object tracks
the 'ui' reference since d4e8aa61370d. See the change to 'archive' for details
about the differences between the output level in the root repo and subrepo 'ui'
object.
The only use for 'ui' in revert is to emit status and warning messages, and to
check the verbose flag prior to printing the action to be performed on a file.
The local repo's ui was already being used to print a warning message in
wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status()
call. Unlike other methods where the matcher is passed along and narrowed, a
new matcher is created in each repo, and therefore the bad() method already used
the local repo's ui.
This no longer needs to be explicitly passed because the subrepo object tracks
the 'ui' reference since d4e8aa61370d. See the change to 'archive' for details
about the differences between the output level in the root repo and subrepo 'ui'
object.
The only use for 'ui' in remove is to emit status and warning messages, and to
check the verbose flag prior to printing files to be removed. The bad() method
on the matcher still uses the root repo's ui, because narrowing the matcher
doesn't change the ui object.
The local repo's ui was already being used to print a warning message in
wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status()
call.
This no longer needs to be explicitly passed because the subrepo object tracks
the 'ui' reference since d4e8aa61370d. See the change to 'archive' for details
about the differences between the output level in the root repo and subrepo 'ui'
object.
The only use for 'ui' in forget is to emit status and warning messages, and to
check the verbose flag prior to printing files to be forgotten. The bad()
method on the matcher still uses the root repo's ui, because narrowing the
matcher doesn't change the ui object.
The local repo's ui was already being used to print a warning message in
wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status()
call.
This no longer needs to be explicitly passed because the subrepo object tracks
a 'ui' reference since d4e8aa61370d. See the change to 'archive' for details
about the differences between the output level in the root repo and subrepo 'ui'
object.
The only use for 'ui' in cat is to emit a status message when a subrepo is
missing. The bad() method on the matcher still uses the root repo's ui, because
narrowing the matcher doesn't change the ui object.
The recursive addremove operation occurs completely before the first subrepo is
committed. Only hg subrepos support the addremove operation at the moment- svn
and git subrepos will warn and abort the commit.
The change in 02ecc94fb657 created a problem on Windows and OS X:
--- /usr/local/mercurial/tests/test-issue660.t
+++ /usr/local/mercurial/tests/test-issue660.t.err
@@ -47,6 +47,8 @@
Should succeed - shadow removed:
$ hg add b
+ adding b/b
+ b/b does not exist!
Prior to the failing 'hg add', the file 'b/b' was added and committed, then 'b'
was recursively deleted from the filesystem, file 'b' was created and the delete
was recorded with 'hg rm --after'. This add is attempting to record the
existence of file 'b'.
A filesystem that is not case sensitive prevents dirstate.walk() from skipping
its step 3, and step 3 has the effect of inserting removed files into the walk
list. The Linux code doesn't run through step 3, and didn't exhibit the
problem. It's not clear why a non case sensitive filesystem triggers step 3,
given that the path normalization occurs in step 2.
Prior to 02ecc94fb657, part of the check here was 'f not in repo.dirstate'
instead of 'f not in wctx'. Files in the 'r' state are filtered out of
context.__contains__() but not dirstate.__contains__(). Therefore the removed
file name wasn't added to the list of files to add when checking against
dirstate. That change was to allow removed files to be readded, but adding a
file that doesn't exist is nonsensical. If the user specifies a missing file,
it will be an exact match and will still fail.
Previously, any files relative to the root of the repo that match the -I
patterns would be deleted, but the command exited with 1 after printing a
warning:
$ hg remove -S -I 're:.*.txt' .
removing sub1/sub2/folder/test.txt
removing sub1/sub2/test.txt
not removing .: no tracked files
Like 'forget', git and svn subrepos are currently not supported. Unfortunately
the name 'remove' is already used in the subrepo classes, so we break the
convention of naming the subrepo function after the command.
I accidentally did 'hg forget .' and tried to undo the operation with
'hg add .'. I expected the files to be reported as either modified or
clean, but they were still reported as removed. It turns out that
forgotten files are only added back if they are listed explicitly, as
shown by the following two invocations. This makes it hard to recover
from the mistake of forgetting a lot of files.
$ hg forget README && hg add README && hg status -A README
C README
$ hg forget README && hg add . && hg status -A README
R README
The problem lies in cmdutil.add(). That method checks that the file
isn't already tracked before adding it, but it does so by checking the
dirstate, which does have an entry for forgotten files (state 'r'). We
should instead be checking whether the file exists in the
workingctx. The workingctx is also what we later call add() on, and
that method takes care of transforming the add() into a normallookup()
on the dirstate.
Since we're changing repo.dirstate into wctx, let's also change
repo.walk into wctx.walk for consistency (repo.walk calls wctx.walk,
so we're simply inlining the call).
Amend will reuse the original username if a new one is not provided
with -U, but obsolete.createmarkers() only considers ui.username() for
the obsolete marker's metadata. Allowing the metadata field to be
spoofed seems to defeat the point of the field in the first place.
This covers 'evolve amend' and 'ci --amend' with evolve enabled.
Without this, the transaction aborts but the parent changeset is set to -1. The
corresponding test will be added to evolve separately.
The basic obsolete option is allowing the creation of obsolete markers. This
does not enable other features, such as allowing unstable commits or exchanging
obsolete markers.
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
A `baseset` has multiple cached results and will get even more in the future.
Making it an object "populated once" like the other smartsets makes it both safer
and simpler. The append method will be removed at some point.
When 62900f2373fa introduced phases to the `hg log --debug` output, it
also disabled outputting public phase. At the same time, it always
shows phases in the default template, `hg log --debug -T default`.
Those two should produce the same output, but they don't.
I think it makes a lot more sense to always show all phases. There's
already loss of backwards compatibility in this case when using a
newer hg on an old hg repo, since draft commits will show up in the
output of `hg log --debug`.
Finally, I just don't think that any sort of information should be
hidden with --debug. This flag should be about showing as much
information as possible.
Akin to b5baef1e39f6 which did this for `hg log`, the following sets
the correct phase for the {phase} keyword when the context is a parent
of the current cset. This allows templates such as the following to be
defined,
parent = '{label("log.parent changeset.{phase}",
"parent: {rev}:{node|formatnode}")}\n'
which when called on a parent (e.g. with the `parents` template
keyword), will produce the correct phase.
These files were previously not backed up because the backup mechanism was not
smart enough. This leads to data lose for the user since uncommitted contents
were discarded.
We now properly move the modified version to <filename>.orig before deleting it.
We have to use a small hack to do a different action if "--no-backup" is
specified. This is needed because the backup process is actually a move (not a
copy) so the file is already missing when we backup. The internet kitten is a
bit disapointed about that, but such is life.
This patch concludes the "lets refactor revert" phases. We can now open the
"Lets find stupid bug with renames and merge" phases.
I'm sure that now that the code is clearer we could do it in another simpler
way, but I consider the current improvement good enough for now.
Those files need to be backed up but are currently not. We compute the set of
them to be able to use a different backup strategy in the next changeset.
"check" behaves as backup did before. We check if the current file differs
from destination and we create a backup if it does. This is used for untracked
files that will be overwritten by formerly-deleted files. We have to do the manual
check since no status output can provide the content comparison.
"backup" is now doing unconditional backup. This can be used for files seen as
modified compared to both the target and the working directory. In such a case, we
know that the file differs from target without actually comparing any content.
This new "backup" strategy will be especially useful in the case of files added
between the target and the working directory -parent- with additional modifications
in the working directory -itself-. In that case we know we need to back it up, but we
cannot run the content check as the files does not exists in target.
The current backup value may have two different values:
1. Do not try to do backup
2. Do backup if applicable
We are about to move to:
1. Do not try to do backup
2. Do backup if applicable
3. Do backup in all cases
So we change the current values to make room for the new one.
Since 266cfa7de44d, --template option is ignored if --style is specified,
which is wrong according to the doc of show_changeset():
Display format will be the first non-empty hit of:
1. option 'template'
2. option 'style'
...
On large repos, hg revert --all can take over 13 seconds. This is mainly due to
it walking the tree three times: once to find the list of files in the
dirstate, once to find the list of files in the target, and once to compute the
status from the dirstate to the target.
This optimizes the hg revert --all case to only require the final status. This
speeds it up to 1.3 seconds or so (with hgwatchman enabled).
Further optimizations could be done for the -r NODE and pattern cases, but they
are significantly more complex.
A future patch will be reorganizing this section of the code into two paths, and
targetsubs complicates this by existing in the middle of one path, but not the
other. We fix that by moving it 200 lines down, to the only place it's used.
Before this patch, no message is shown for failure of merging at "hg
import".
In such case, merging patch is imported as a normal revision silently,
and it may confuse users.
For simplicity, this patch recommends just using "--exact", even
though importing the merging patch itself is possible without it if:
- the hash of the 1st parent in the patch is equal to one of the
patch imported just before (or the parent of the working
directory, for the 1st patch of the series), and
- the hash of the 2nd parent in the patch is known in the local
repository
Previously, there was a copy / paste error with using the current changeset's
phase information. We now look up the parent context explicitly.
The line was too long so it is stored into a variable first.
We used to have --style nosuch to list templates, but --style is now
merged with --template/-T where random strings are acceptable
templates. So we reserve 'list' to allow listing templates.
This patch makes commit message shown in text editor customizable by
template. For example, this can advertise:
- sample commit messages for routine works,
- points to call attention before commit,
- message of the day, and so on
To show commit message correctly even in problematic encoding, this
patch chooses the latter below:
- replace "buildcommittext" with "buildcommittemplate" completely
- invoke "buildcommittemplate" only if '[committemplate] changeset'
is configured explicitly
For example, if multibyte character ending with backslash (0x5c) is
followed by ASCII character 'n' in the customized template, sequence
of backslash and 'n' is treated as line-feed unexpectedly (and
multibyte character is broken, too).
This corruption occurs in 'decode("string-escape")' while parsing
template string.
Added + deleted file are files that need to be untracked from the dirstate but
that are already missing on disk. The current `_performrevert` code is handling
that with exception catching. We will be able to do better with a dedicated set.
The distinction between "remove" and "forget" used to be in special logic
checking for the state of the file in the dirstate. Now that we have dedicated
filtering, we can stop relying on this logic and have two distinct actions.
These two kinds of files are handled differently. One is deleted and the other
is just forgotten (the file is untracked but left in place). The distinction is
done in the `_performrevert` code itself and we would like to get ride of this.
This wraps all the locations of dirstate.setparent with the appropriate
begin/endparentchange calls. This will prevent exceptions during those calls
from causing incoherent dirstates (issue4353).
Such unknown files may need to be backed up. Having them identified beforehand
will help simplify the backup logic.
We now use different sets with different backup strategies.
During the silicon age, humans on planet Earth discovered the use of
variables. This marvelous invention let them improve both code
readability and performance.
Now that we removed the (hopeless) attempt to backup file we knew to be
missing in the target changeset, we can stop checking if the file exists in
the target changeset.
There is only one case where a backup is required in the `dsadded` set, and the
current backup mechanism fails to handle it. So we stop trying to do backups at
all for now. This will help us to simplify the backup code and finally fix
this backup issue.
This allow extensions that mess with the storage layer (remotefilelog,
largefile) to prefetch any data that will be accessed during the revert
operation.
We are currently fetching more data than theoretically required because the
backup code is a bit stupid. Future patches will improve that.
The internal API used IOError to indicate that a file should be marked as
removed.
There is some correlation between IOError (especially with ENOENT) and files
that should be removed, but using IOErrors to represent file removal internally
required some hacks.
Instead, use the value None to indicate that the file not is present.
Before, spurious IO errors could cause commits that silently removed files.
They will now be reported like all other IO errors so the root cause can be
fixed.
Before this patch, external editor is invoked when imported patch has
no commit message, even if "--exact" is specified. Then, exact-ness is
broken, because empty commit message causes failure of committing.
This patch avoids editor invocation at importing with "--exact" for
exact-ness, because commit message in the patch should be kept as it
is in such case, even if it is empty.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
other in "hg import" without "--bypass" case.
This patch assumes "editform" variations for "hg import" below:
import.normal.normal
import.normal.merge
import.bypass.normal
import.bypass.merge
Unlike other patches in this series, this patch uses "editor.sh"
instead of "checkeditform.sh" for the name of the script to check
"HGEDITFORM", because it has to do more than checking "HGEDITFORM".
To invoke editor forcibly in "test-import-merge.t", this patch creates
the patch not having patch description as "merge.nomsg.diff".
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "amend.normal" and "amend.merge" as ROUTE of
"editform" instead of "amend", to distinguish merge commits from other
in "hg commit --amend" case.
"editform" argument for "getcommiteditor" is decided according to the
format below:
COMMAND[.ROUTE]
- COMMAND: name of command
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch uses "normal.normal" and "normal.merge" as ROUTE of
"editform" instead of "normal", to distinguish merge commits from
others in "hg commit" without "--amend" case.
This patch assumes "editform" variations for "hg commit" below:
commit.normal.normal
commit.normal.merge
commit.amend.normal
commit.amend.merge
"mergeeditform" is factored out for subsequent patches. It takes
"ctxorbool" argument, because context object can't be passed in some
cases.
We check for rename information in the dirstate. This is probably not enough to
preserve this behavior when using an explicit target rev.
I just spotted this while working on this code, but this is outside the scope
of my series so I'm just adding a comment to highlight this suspicious
situation.
All those checks were here to catch cases where files were not modified in
dirstate but were different in the target revision. This is now properly handled
by calling status on the target node too.
In case of merge, file that are actually added can be reported as modified. This
is currently handled by special-case code. We detect it beforehand instead. This
will lets use remove the special-case code at some point in the future.
There are multiple possible cases for added files. But it's all handled by magic
much lower in the stack. We document them, simplify the codes and move on.
At the external editor invocation for committing, the value specified
as "editform" for "cmdutil.getcommiteditor" is in "HGEDITFORM".
This enables external editor to do own customization according to
commit types.
Using status information against the target ensures we are catching all
files with modifications that need reverting.
We still need to distinguish fresh modifications for backup purpose.
test-largefile is affected because it reverted a file that needs no content
change.
We had a special case for file not caught by any categories. It was
aimed at files missing in wc and wc's parent but existing in the target
revision. This is now properly handled using status information.
Using status information against the target to make sure we are catching all
files that need to be re-added.
We still need to distinguish fresh removal because they use a different
message.
Tracking clean files is the simplest way to be able to reports files that need
no changes. So we explicitly retrieve them.
This fixes a couple of test outputs where the lack of changes was not reported.
