As we are going to introduce status again other revision we needs to distinguish
between data from dirstate status and the other one. We prefix the existing data
with "ds" to highlight this.
Currently, revset is using information from dirstate status and alter its
behavior whenever the file exist in the target manifest or not. This tests are
done a big for loop. We move this member ship testing outside of the loop and
simplifies associates data structure.
This is a step toward a cleaner implementation of revert based on status.
Before this patch, each template definitions for 'changeset*' in
'[committemplate]' section have to be written fully from scratch,
even though many parts of them may be common.
This patch uses '[committemplate]' section like as the map file for
the style definition. All items other than 'changeset' can be referred
from others.
This can reduce total cost of template customization in
'[committemplate]' section.
When the commit template other than '[committemplate] changeset'
is chosen by 'editform', putting '[committemplate] changeset'
value into the cache of the templater causes unexpected result,
because the templater stores the specified (= chosen) template
definition into own cache as 'changeset' at construction time.
This is the reason why '[committemplate] changeset' can't be referred
from others.
Before this patch, '[committemplate] changeset' definition is shared
between all actions invoking 'commitforceeditor()'.
This prevents template definition from showing action specific
messages: for example, 'hg tag --remove' may need specific
message to call attention, but showing it may be redundant for
other actions.
This patch looks commit template definition up by specified
'editform' introduced by prior patches. 'editform' are
dot-separated list of names, and treated as hierarchical one.
This patch passes 'editform' argument according to the format below:
COMMAND[.ROUTE]
- ROUTE: name of route, if there are two or more routes in COMMAND
In this patch, 'normal' and 'bypass' are used as ROUTE.
This patch passes 'editform' argument according to the format below:
COMMAND[.ROUTE]
- ROUTE: name of route, if there are two or more routes in COMMAND
In this patch, 'normal' and 'amend' are used as ROUTE.
This information will be used to switch '[committemplate] changeset'
definition according to its purpose in the subsequent patch.
This information also makes it easier to hook commit text editing only
in the specific cases.
It's not uncommon for a user to want to run log with a pattern or directory name
on the history of their current commit. Currently we prevent that, but
I can't think of any reason to continue blocking that.
This commit removes the restriction and allows 'hg log -f <dir/pat>'
The arguments to log --patch --follow are expected to be exact paths.
This will be used to make manifest filtering for these cases more efficient in
upcoming patches.
Previously, the 'patch' code for hg log --patch --follow would try to resolve
patterns relative to the repository root rather than the current working
directory. Fix that by using match.files instead of pats, as done elsewhere
nearby.
This separation makes it easier to extend/hook building commit text
from the specified context.
This patch uses 'committext' instead of 'edittext' for names of newly
added variable and function, because the former is more purpose
specific than the latter, even though 'edittext' in 'buildcommittext'
is left as it is to reduce amount of diff.
Now that revsets work in a lazy way, log code can be changed to parse every
option into a revset and then evaluate it lazily.
Now expressions like
"hg log -b default -b ."
are converted into a revset using the same code as graphlog.
Since decorators are evaluated at module load time and since the
@command decorator imports commands, the norepo variable (along with
its friends) may not be declared yet. These variables are now declared
before @command usage to ensure they are present.
This patch changes the calling signature of memfilectx's __init__ to fall in
line with the other file contexts.
Calling code and tests have been updated accordingly.
revert was always using p1 as parent. This created some minor misbehavior when
reverting against p2. See test change for an example of that.
This is also a useful cleanup for coming refactoring to revert.
This makes absolutely no functional changes. The default value for
node1 is already the same as the current value of parent. But to be
able to properly use the second parent in merge context, we have to
start to be a bit more explicit about what we compute the status
against.
The dispatch table used to be:
- action if in target manifest
- action if not in target manifest
- make backup if in target manifest
- make backup if not in target manifest
We turn this into two (action, make backup) tuples.
This helps both readability of the dispatch table and handling of each case.
This also prepares a refactoring where the different actions we performs, whether
"file is in target manifest" or not, are determined before reaching this loop.
We had 4 different variables to hold the list of the 4 possibles
actions. I'm grouping them in a single dictionary for a few reasons.
First, it makes it clearer they are all related and meant to be the
final actions performed by revert. Second this simplifies the parameter
of the _performrevert function. Finally the two elements in each entry
(list and message) have a different consumers in different functions,
this change will make it easier to split them in a later commit.
I spend some time understanding how this part of the revert code is
working. I'm adding some comments to help the code readability. I
expect most of them to disappear in a coming refactoring. But the
refactoring should be easier to follow with the comment.
The `hg import` command gains a `--partial` flag. When specified, a commit will
always be created from a patch import. Any hunk that fails to apply will
create .rej file, same as what `hg qimport` would do. This change is mainly
aimed at preserving changeset metadata when applying a patch, something very
important for reviewers.
In case of failure with `--partial`, `hg import` returns 1 and the following
message is displayed:
patch applied partially
(fix the .rej files and run `hg commit --amend`)
When multiple patches are imported, we stop at the first one with failed hunks.
In the future, someone may feel brave enough to tackle a --continue flag to
import.
This patch introduces "outgoinghooks" to avoid redundant outgoing
check for "hg outgoing" in other than "commands.outgoing" (or utility
functions used by it).
This patch introduces "summaryremotehooks" to avoid redundant
incoming/outgoing check for "hg summary" in other than
"commands.summary".
Only if "--remote" is not specified for "hg summary", hooks registered
in "summaryremotehooks" are invoked with "None" as "changes" argument
at first, and they should return tuple of two booleans meaning
"whether incomings are needed" and "whether outgoings are needed".
If no hooks return tuple containing "True", "hg summary" does nothing
any more, because incoming/outgoing check is not needed.
Otherwise, hooks are invoked again: at this time, "changes" argument
refers the result of incoming/outgoing check.
This patch also prevents RepoError from being raised if "--remote" is
not specified for "hg summary", because of backward compatibility for
"hg summary --large" without "--remote".
The cat command with an explicit path into a subrepo is now handled by invoking
cat on the file, from that subrepo. The previous behavior was to complain that
the file didn't exist in the revision (of the top most repo). Now when the file
is actually missing, the revision of the subrepo is named instead (though it is
probably desirable to continue naming the top level repo).
The documented output formatters %d and %p reflect the path from the top level
repo, since the purpose of this is to give the illusion of a unified repository.
Support for the undocumented (for cat) formatters %H, %R, %h, %m and %r was
added long ago (I tested back as far as 0.5), but unfortunately these will
reflect the subrepo node instead of the parent context.
The previous implementation was a bit loose with the return value, i.e. it would
return 0 if _any_ file requested was cat'd successfully. This maintains that
behavior.
1fc59036a99b introduces "--edit" option into "hg commit", but it
doesn't work for "hg commit --amend", because 1fc59036a99b prepares
for editor invocation only around "commitfunc()" internal function,
which is used only for temporary amend commit by "cmdutil.amend()".
Actual commit message editing is executed in "cmdutil.amend()".
This patch invokes editor forcibly when "--edit" option is specified
for "hg commit --amend", even if commit message is specified
explicitly by "--message" or "--logfile".
This patch also removes useless handling for commit message and editor
invocation around "commitfunc()" internal function.
Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
Before this patch, commit message (may be manually edited) for "commit
--amend" is never saved into ".hg/last-message.txt", because it uses
"localrepository.commitctx()" instead of "localrepository.commit()":
saving into ".hg/last-message.txt" is executed only in the latter.
This patch saves commit message for "commit --amend" into
".hg/last-message.txt" just after user editing.
This is the simplest implementation to fix on stable. Editing and
saving commit message for memctx should be centralized into the
framework like "localrepository.commit()" with "editor" argument or so
in the future.
__getitem__ is a method that is not implemented lazily on many of the new
classes and it can be easily replaced with a structure that takes advantage of
the new lazy implementations instead.
__getitem__ is a method that is not implemented lazily on many of the new
classes and it can be easily replaced with a structure that takes advantage of
the new lazy implementations instead.
Before this patch, "hg commit --amend --secret" doesn't create new
amend changeset as secret, even though the internal function
"commitfunc()" passed to "cmdutil.amend()" make "phases.new-commit"
configuration as "secret" temporarily.
"cmdutil.amend()" uses specified "commitfunc" only for temporary amend
commit, and creates the final amend commit changeset by
"localrepository.commitctx()" directly with memctx.
This patch creates new amend changeset as secret correctly for
"--secret" option, by changing "phases.new-commit" configuration
temporarily before "localrepository.commitctx()".
With this small refactoring, the computation of the action to perform and the
actual change to the disk happen in different function. This allows extension to
wrap the later in case of need. The initial motivation is the `remotefilelog`
extension that need to prefetch all the file content to be checked out.
Now log can work in a lazy way and get results as soon as they are processed.
Performance Benchmarking:
$ time hg log -l1 -qr "branch(default)"
0:3a6a38229d41
real 0m2.303s
user 0m2.252s
sys 0m0.048s
$ time ./hg log -l1 -qr "branch(default)"
0:3a6a38229d41
real 0m0.238s
user 0m0.199s
sys 0m0.037s
We extract the `tryone` function into the `cmdutil` module. A lot of the command
context have to be passed to the utility function, but having and explicit
declaration will allow extension to wrap it. This will allows use to make
changeset evolution related experiment in dedicated extension.
Improving the API of this function is noble goal but outside of the scope of
this patches.
This patch introduces "finishdesc" and "extramsg" arguments into
"getcommiteditor()" for specific usages in MQ.
"finishdesc" will be used to treat the commit message as "[mq];
patch-file-name" (default MQ commit message), if it is left as empty,
instead of aborting commit process.
"extramsg" will be used to show the line below:
HG: Leave message empty to use default message
instead of:
HG: Leave message empty to abort commit
This patch also enhances "test-import-bypass.t" and "test-import.t",
because "hg import" hasn't been explicitly tested around editor
invocation and "--edit" option.
This patch explicitly tests below:
- with "--bypass" (regardless of "--edit"):
- not invoked, if the patch contains the commit message
- not invoked, if the commit message is explicitly specified
- invoked, otherwise (just adding comment)
- without "--bypass":
- with "--edit":
- not invoked, if "--no-commit" is not specified
- invoked, otherwise
- without "--edit":
- not invoked, if the patch contains the commit message
- not invoked, if "--message" or "--logfile" is specified
(just adding comment)
- invoked, otherwise
"getcommiteditor()" can simplify code paths to choose commit editor
according to '--edit' option as below:
before:
editor = cmdutil.commiteditor # or editor = None/False
if opts.get('edit'):
editor = cmdutil.commitforceeditor
after:
editor = cmdutil.getcommiteditor(**opts)
"getcommiteditor()" accepts option arguments not in "opts" style but
in "**opts" style, because some code paths want to invoke it with just
explicit "edit=True" argument (building dictionary is redundant).
Before the templater got extended for nested expressions, it made
sense to decode string escapes across the whole string. Now we do it
on a piece by piece basis.
There is a potential race here, which I suspect I've spotted in the wild, where
something reads the pid file after the parent exits but before the child has
had a chance to write to it. Moving writing the file to the parent causes this
to no longer be an issue.
Running "hg log <pattern or directory>" on large repos took a very, very long
time because it first read ctx.files() for every commit before even starting to
process the results.
This change makes the ctx.files() check lazy, which makes the command start
producing results immediately.
This adds a registration point and check functions that will allow
commands to check if multistep operations like an interrupted graft or
rebase are in progress before proceeding.
A few places in the code use 'if not len(revlog)' to check if the revlog
exists. Replacing this with 'not filerevlog' allows alternative revlog
implementations to override __nonzero__ to handle this case without
implementing __len__.
This moves the logic that determines which changesets to process during a
'hg log foo.txt' command. Putting it in its own function allows extensions
to modify how the file log is traversed. For instance, the current
implementation uses filelog revs heavily. Other implementations may not have
filelog revs available.
The function throws an exception if the traversal is not possible via the
filelog, so the parent function can do things the slow way if necessary
(by walking the entire commit history).
Aside from the exception throwing, no logic is changed.
Consider the following repo:
0 -- 1 (renames a to b)
\
- 2
If we're rebasing 2 onto 1, then duplicatecopies is called with arguments (2,
1). copies.pathcopies goes backwards from 1 to 0 and returns the pair dst = a,
src = b. Of course, since we're working on top of 2, at this point a doesn't
exist in the dirstate.
Extra entries in the copymap are currently harmless because the copymap is
only queried for items in the dirstate map. However, if the dirstate.copy
method becomes one of the sources used to determine which files have changed,
this will prove problematic.
Note that we can't avoid going backwards in general -- consider this repo:
0 -- 1 (renames a to b)
\
- 2 (renames a to c)
Rebasing 2 onto 1 should produce a rename from b to c.
In a large repo, running a command like "log -l1 -p" was expensive because
it would always traverse 8 commits, as 8 was the initial window size.
We now choose the lesser of 8 or the limit, speeding up the "log -l1 -p"
case by a factor of 5.
We create a new function commitstatus() in cmdutil that handles printing
the status message(s) after a commit. This will allow other commit-like
commands to use it, and in particular is step 2 towards removing
backout's call to commands.commit.
'export' is the official export format and used by patchbomb, but it would only
show date as a timestamp that most humans might find it hard to relate to. It
would be very convenient when reviewing a patch to be able to see what
timestamp the patch will end up with.
Mercurial has always used util.parsedate for parsing these headers. It can
handle 'all' date formats, so we could just as well use a readable one.
'export' will now use the format used by 'log' - which is the format described
as 'Unix date format' in the templating help. We assume that all parsers of '#
HG changeset patch'es can handle that.
This violated user expectation. Updated the code to clobber files, but
preserve the behavior of appending multiple patches requested in a
single export. Includes tests.
If there is an active bookmark while committing, the bookmark name
will be visible inside the commit message helper, below the branch
name.
This should make easier for the user to detect a mistaken commit
parent, while working for example with a bookmark centric workflow
like topic branches.
The active bookmark is checked to be in the working directory, as
pointed by Kevin Bullock, because otherwise committing would not
advance it. In other words, this would not show the active
bookmark name if the user changed the working tree parents with
'hg debugsetparents', for example.
Add sorted() in places found by testing with PYTHONHASHSEED=random and code
inspection.
An alternative to sprinkling sorted() all over would be to change substate to a
custom dict with sorted iterators...
The dispatch code now enables filtering of "hidden" changesets globally. The
filter is installed before command and extension invocation. The `--hidden`
switch is now global and disables this filtering for any command.
Code in log dedicated to changeset exclusion is removed as this global filtering
has the same effect.
When log is not given the --hidden option, hidden revision are not shown. We
move the implementation from manual checking at display time to changelog
filtering.
This is the first official usage of the hidden filtering.
The active bookmark were moved to the temporary commit. When the transaction
were rollbacked, the bookmark were lost.
We now temporarly disable the bookmark to prevent this effect.
The temporary commit created by amend update the dirstate. If the final commit
fails, we need to invalidate the change made to the dirstate, otherwise the
release of the wlock will write the dirstate created after the rollbacked
temporary commit.
This dirstate writing logic should probably be handled in the same object than
the transaction one. However such change are too big for stable.