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).
Functions like getbundle and classes like unbundle10 really manipulate
changegroups and not bundles. A HG10 bundle is the same as a changegroup
plus a small header, but this is no longer the case for a HG2X bundle,
so it's better to separate the names a bit.
The hgrc for user config is typically different from the hgrc at the
system-wide or repository level. This patch provides different sample
hgrcs for each level. Sometimes when copying repos around, the copy or
the original don't have a default path yet, so at least for `hg config
-l`, this ought to provide a more reasonable default and suggestions
of what typically goes there.
The actual sample configs go in the config.py file, to minimise
clutter. In order to avoid an unnecessary import, the corresponding
import for this dictionary is at the file level.
Before this patch, "hg import" allows combination of "--exact" and
"--edit", even though editing commit message breaks exact-ness.
This patch disallows meaningless combination of "--exact" and "--edit".
We add a ``--record-parents`` flag to debugobsolete. This can be used to record
parent information in the marker when the precursors are known locally. This
will be useful to test the "relevant markers" computation.
"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 are about to add more arguments to this function (date, parents, etc).
Passing metadata as a keyword argument gives us more flexibility when adding
them.
In all the remaining cases the comprehension variable is used for the same
thing as a previous loop variable.
This will mute some pyflakes "list comprehension redefines" warnings.
We now pass a transaction option to this phase movement function. The
object is currently not used by the function, but it will be in the
future.
All call sites have been updated. Most call sites were already enclosed in a
transaction for a long time. The handful of others have been recently
updated in previous commit.
We now pass a transaction option to this phase movement function. The object
is currently not used by the function, but it will be in the future.
All call sites have been updated. Most call sites were already enclosed in a
transaction for a long time. The handful of others have been recently
updated in previous commit.
The retractboundary function remains to be upgraded.
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 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, 'add' and 'remove' 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, ROUTE is omitted.
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, ROUTE is omitted..
Since --force determines the list of revisions to be grafted, it doesn't really
make sense for users to have to keep typing --force --continue as they continue
grafting.
If stdout is piped, status message won't be flushed until client connects to
the server and access log is written to stdout. It seems bad idea to queue
start-up banner of server process.
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 will make resolve use correct locking and thus make it more safe.
Resolve is usually a long running command spending a lot of time waiting for
user input on hard problems. It is thus a real world scenario to start multiple
resolves at once or run other commands (such as up -C and merge) while resolve
is running. Proper locking prevents that.
Revset calls use to return a list. Graft use to mutate that list. We cannot do
this anymore leading to a crash when grafting multiple changeset with a revset.
File ".../mercurial/commands.py", line 3117, in graft
revs.remove(rev)
AttributeError: '_addset' object has no attribute 'remove'
We are late in code-freeze so we make the shortest possible fix by turning it
back to a list.
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.
If two revisions are linearly related, there will only be one ancestor, and
commonancestors and commonancestorsheads would give the same result.
commonancestorsheads is however slightly simpler, faster and more correct.
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.
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 broke some internal automation that was quite reasonably checking for
unresolved files as a way to determine whether a merge happened cleanly. We
still abort for resolve --mark etc.
The previous documentation pointed to the export command, but even if the user
recognized that instead of only reading the cat specific list of rules, not all
of the export rules applied anyway (specifically %N, %n and %m). The new items
are a copy/paste from export's list. These rules have existed since at least
version 0.5.
Note that %m gets substituted with 'None' because the commit message isn't
passed to cmdutil.makefilename(). %R and %r are currently effectively the same,
since no revwidth is passed, however they both work.
There aren't any existing tests for these rules, so they are added to prevent
future regression.
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 makes "_outgoing()" return peer object for remote
repository, to avoid re-execution "expandpath()", "parseurl()", and
"peer()" on caller side for specified URL.
This patch makes "_outgoing()" return empty list instead of "None", if
there are no outgoing changesets, because:
- returning "None" requires callers to examine whether returned
value is "None" or not explicitly, if callers want to execute loop
on returned value, but
- there are no explicit needs to return "None"
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".
This patch separates checking incoming/outgoing and showing remote
summary, as a preparation for refactoring in succeeding patches,
because:
- checking incoming/outgoing may be needed, even if "--remote" is
not specified for "hg summary"
- checking incoming/outgoing may not be needed simultaneously
"hg summary --large" without "--remote" is typical case for these.
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.
"--force-editor" option for "hg commit" has been useless since
074e6345f65e, which makes "commands.tag()" invoke "cmdutil.commit()"
directly instead of "commands.commit()" with "--force-editor" internal
option.
This patch abolishes useless "--force-editor" internal option for "hg
commit".
The --edit/-e option for the 'commit' command forces editor, even when a
commit message has been provided already by other means, such as by the -m or
-l options.
This is a gratuitous code move aimed at reducing the localrepo bloatness.
The method had few callers, not enough to be kept in local repo.
The peer API remains unchanged.
Before this patch, "contrib/check-code.py" can't detect these
problems, because the regexp pattern to detect "% inside _()" doesn't
suppose the case that the format string and "%" aren't placed in the
same line.
This patch replaces "\s" in that regexp pattern with "[ \t\n]" to
detect "% inside _()" problems in such case.
"[\s\n]" can't be used in this purpose, because "\s" is automatically
replaced with "[ \t]" by "_preparepats()" and "\s" in "[]" causes
nested "[]" unexpectedly.
If backout generated no changes to commit, it showed wrong status, "changeset
<target> backs out changeset <target>", and raised TypeError with -v option.
This changes the return code to 1, which is the same as "hg commit" and
"hg rebase".
Before this patch, `hg commit --secret` was not getting propagated
correctly, and subrepos were not getting the commit in the secret
phase. The problem is that subrepos get their ui from the base repo's
baseui object and ignore the ui object passed on to them. This sets
and restores both ui objects with the appropriate option.
Before this patch, manually edited commit message for "hg tag -e"
isn't saved into ".hg/last-message.txt" until it is saved by
"localrepository.savecommitmessage()" in "localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "hg tag -e" into
".hg/last-message.txt" just after user editing. This patch doesn't
save the message specified by -m option (-l is not supported for "hg
tag") as same as other commands.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
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()".
We can use the "other" data from the recorded merge state instead of inferring
what the other could be from working copy parent. This will allow resolve to
fulfil its duty even when the second parent have been dropped.
Most direct benefit is fixing a regression in backout.
When pulling changes from a compressed bundle Mercurial first uncompresses it
to a temporary file in .hg directory. This file will not be deleted unless
the bundlerepo (other) is explicitly closed.
This is similar to cleanup that occurs after incoming.
Before this patch, internal function "display()" of "hg grep" is not
efficient for "-l"/"--files-with-matches", because loop is continued,
even after the first matching is found in the specified file.
This patch exits loop immediately, if matching is found for
"--files-with-matches".
In this case, "before is None" is equal to "opts.get('files_with_matches')".
Before this patch, internal function "display()" of "hg grep" stores
whether matching is already found or not into the dictionary
"filerevmatches" by "(fn, rev)" tuple as the key.
But this is redundant, because:
- "filerevmatches" is local variable of "display()", so each
"display()" invocations don't affect others
- both "fn" and "rev" (gotten from "ctx" argument) are never changed
in each "display()" invocations
Then, "filerevmatches" should have only one entry at most, and "(fn,
rev) in filerevmatches" should be equal to "found".
This patch uses "found" instead of "filerevmatches" examination for
efficiency.
Before this patch, to check whether the file in the specified revision
is binary or not, "util.binary()" is invoked via internal function
"binary()" of "hg grep" once per a line of "hg grep" output, even
though binary-ness is not changed in the same file.
This patch reuses the first "util.binary()" invocation result by
annotating internal function "binary()" with "@util.cachefunc".
Performance improvement measured by "hgperf grep -r 5e9e7af9ae01 vfs
mercurial/scmutil.py":
before this patch:
! wall 0.024000 comb 0.015600 user 0.015600 sys 0.000000 (best of 118)
after this patch:
! wall 0.023000 comb 0.015600 user 0.015600 sys 0.000000 (best of 123)
Status of recent(5e9e7af9ae01) "mercurial/scmutil.py":
# of lines: 919 (may affect cost of search)
# of bytes: 29633 (may affect cost of "util.binary()")
# of matches: 22 (may affect frequency of "util.binary()")
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.
This change adds to the output of "hg debuginstall" information about the
Python being used by Mercurial. It adds both the path to the Python
executable (i.e. the value of sys.executable) and the version of Python
(specifically the major, minor, and micro versions).
Below is an example of what the output looks like after this change.
The marked lines are the new output lines:
$ hg debuginstall
checking encoding (UTF-8)...
-->showing Python executable (/Users/chris/.virtualenvs/default/bin/python)
-->showing Python version (2.7.6)
checking Python lib (/Users/chris/.virtualenvs/default/lib/python2.7)...
checking installed modules (/Users/chris/mercurial)...
checking templates (/Users/chris/mercurial/templates)...
checking commit editor...
checking username...
no problems detected
Note that we use the word "showing" without an ellipsis for the new lines
because, unlike the other lines (except for "Python lib" which will be
adjusted in a subsequent commit), no check follows the display of this
information.
