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.
Typical use case is to clone repository through command server. Clone may
require user interaction, so command-server protocol is beneficial over
raw stdio channels.
When user type "hg push" command then this patch helps user by
providing hint if no default path is configured.
Second patch is the test coverage, to test the change behaviour of
first patch.
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.
Missing templates where not reported as a problem, only an empty bracket
were shown as indication of no found template directory:
$ hg debuginstall
*...some lines*
checking templates ()...
*...some lines*
no problems detected
Now the problem is reported and extended with some information. The style
of the messages is adapted to the other messages of debuginstall.
When no templates directories exist, it writes:
$ hg debuginstall
*...some lines*
checking templates ()...
no template directories found
(templates seem to have been installed incorrectly)
*...some lines*
1 problems detected, please check your install!
When the template map is not found, it writes:
$ hg debuginstall
*...some lines*
checking templates (/path/to/mercurial/templates)...
template 'default' not found
(templates seem to have been installed incorrectly)
*...some lines*
1 problems detected, please check your install!
When the template map is buggy the message is the same as before. The error
message is shown before the line "(templates seem ...)".
No test is added because testing this failure is complicated. It would
require to modify the templates directory of the mercurial installation,
or to monkey patch a function (os.listdir or any from mercurial.templater)
by a test extension.
When updating to a bookmark, mention that the bookmark is now
active. This is a reminder that update does not move the
current bookmark if an explicit target is given - instead
it activates that target.
This patch also eliminates "forceeditor" no more referred.
This patch doesn't change any tests like as preceding patches, because
editor invocation is already tested well.
Before this patch, "hg backout" examines "--message" and "--logfile"
options explicitly.
But this examination is redundant, because "commitfunc()" can receive
the result of same examination by "cmdutil.logmessage()" in
"cmdutil.commit()" through "message" argument.
This patch avoids redundant message examination by "message"
examination in "commitfunc()".
Special case the single file case in hg cat. This allows us to avoid
parsing the manifest, which shaves 15% off hg cat perf. This is worth
it, since automation often uses hg cat for retrieving single files.
In some case Backout silently succeeded to back out but left all the change
uncommitted. This may be confusing for user so this changeset add a note
reminding to commit. Other backout case already actively informs the user about
created commit.
Before the changeset the backout process was:
1) go to <target>
2) revert to <target> parent
3) update back to changeset we came from
The two update steps can takes a very long time to move back and forth unrelated
file change between <target> and current working directory.
The new process is just merging current working directory with the parent of
<target> using <target> as ancestor. This give the very same result but skip
the two updates. On big repo with a lot of files and changes that save a lots of
time (x20 for one week window).
The "merge" version (hg backout --merge) is still done with upgrades. We could
imagine using in memory commit to speed it up but this is another fish.
b33db384a66e not only introduced the 'bisect(current)' revset predicate, it
also changed how the 'current' revision is used in combination with --command.
The new behaviour might be ok for --noupdate where the working directory and
its revision shouldn't be used, but it also did that when --command is used to
run a command on the currently checked out revision then it could register the
test result on the wrong revision.
An example:
Before, bisect with --command could use the wrong revision when recording the
test result:
$ hg up -qr 0
$ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters"
changeset 31:58c80a7c8a40: bad
abort: inconsistent state, 31:58c80a7c8a40 is good and bad
Now it works as before and as expected and uses the working directory revision
for the --command result:
$ hg up -qr 0
$ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters"
changeset 0:b99c7b9c8e11: bad
...
Any invocations of bookmarks other than a plain 'hg bookmarks' will likely
cause a write to the bookmark store. These should be guarded by the wlock.
The repo._bookmarks read should be similarly guarded by the wlock if we're
going to be subsequently writing to it.
Upcoming patches will acquire the wlock for write operations, such as make
inactive, but not read-only ones, such as list bookmarks. Separate out the
status messages so that the code paths can be separated.
Push is currently allowed to create a new head if there is a remote
bookmark that will be updated to point to the new head. If the
bookmark is not known remotely then push aborts, even if a -B argument
is about to push the bookmark. This change allows push to continue in
this case. This does not require a wireproto force.
Previously, directories were added with the trailing slash and, if there was
only one completion, then another ambiguous entry was created using '.', as
follows:
$ hg rm mer<TAB>
mercurial/./ mercurial//
This was added in bc559aff745c (though, some logic existed before that) to work
around bash completion adding a space after the sole entry because we treated
directories and files the same. We no longer do that now so we remove this
unneeded code.
Tests have been updated to match this new behavior.
There are currently two different ways we can have no active bookmark:
.hg/bookmarks.current being missing and it being an empty file. This patch and
upcoming ones make an empty file the only way to represent no active bookmarks.
This is the right choice because it matches the state that a new repository
without bookmarks will be in.
When trying to turn a draft changeset into a secret changeset, I was
told:
% hg phase -s .
cannot move 1 changesets to a more permissive phase, use --force
no phases changed
That message struck me as being backwards -- the secret phase feels
less permissive to me since it restricts the changesets from being
pushed.
We don't use the word "permissive" elsewhere, 'hg help phase' talks
about "lower phases" and "higher phases". I therefore reformulated the
error message to be
cannot move 1 changesets to a higher phase, use --force
That is not perfect either, but more in line with the help text. An
alternative could be
cannot move phase backwards for 1 changesets, use --force
which fits better with the help text for --force.
Previously, this required -f because we didn't consider obsolete changesets
(and their children ... or successors of those children, etc.). We now use
obsolete.foreground to calculate acceptable changesets when advancing the
bookmark.
Test coverage has been added.
This patch adds "pushtoremote()", which uses "compare()" to compare
bookmarks between the local and the remote repositories, to replace
pushing local bookmarks in "commands.push()".
On Windows, only double quotation mark can quote command line
arguments.
So, this patch uses double quotation mark to quote command line
arguments in all examples of online help document.
This patch adds more detailed explanation about "--force" to online
help document of "hg push" to prevent novice users to execute "push
--force" easily without understanding about problems of multiple
branch heads in the repository.
This makes `hg pull --update` behave the same wrt the active bookmark as
`hg pull && hg update` does as of 13ea5e437ff8. A helper function,
bookmarks.calculateupdate, is added to prevent code duplication between
postincoming and update.
The old docs emphasized topological heads rather than branch heads and
incorrectly defined branch heads as not having children rather than
descendants.
At the moment, creating secret commits is slightly cumbersome. They
can either be created by changing the default commit phase to secret
or by doing `hg phase --secret --force`. Both of these make secret
commits appear to be like some kind of advanced feature.
Secret commits, however, should be a convenient feature for people who
want to work on a private branch without affecting anyone else. There
should therefore be a prominent and convenient method for creating
secret commits.
Since the default phase is draft and there is no need to use --force
to go from a secret phase to any other phase, this patch
intentionally does not add --draft and --public options.
The --force option in merge does not make what people think it does so
it may not be visible to everyone.
I have local changes and want to pull one's changes which made 2 heads.
The --force option in help says
-f --force force a merge with outstanding changes
so I can expect that I can use it to force the merge and commit it in my
local repository without taking my local changes into account. But
merging with -f keeps local changes and "add" them: they must be
committed or reverted before doing the merge commit. The merge -f cannot
be reverted so it leads my repository in a bad state: cannot commit
merge and don't want to revert/commit local changes yet.
Message in help have been updated to emphasize the fact that local
changes are included in the merge.
