This should be faster and more future-proof. Calls where the result is to be
sorted using util.sort() have been left unchanged. Calls to .items() on
configparser objects have been left as-is, too.
Changes docstrings to begin with a lowercase word. Only docstrings
used in help output is changed.
Scripts are not expected to grep the output of 'hg help' so this
change should pose no problem with regard to the compatibility rules.
hg bisect -c failed with a relative path or when the executable wasn't found.
Use util.find_exe()+os.spawnl() instead of os.spawnlp() and improve the
handling of errors (killed process, exe not found).
Thanks to Georg Brandl for reporting it.
Due to the fix to the pull race, to avoid sending unnecessary
changesets, use changegroupsubset if possible.
This will increase the load on the server.
Parts of the original text were submitted by Hubert Kauker (Hubert
dot Kauker at travelbasys.de). This is a slightly revised version
of Hubert's original text.
In 'hg', we now show a short list of commands, including extension commands.
In 'hg help', we show core commands, a list of enabled extensions, and topics.
The gettext function is just another name for the normal _ function
and it is used for translating docstrings when using _ would make
pygettext.py output a warning.
When looking up a help topic, the key is now only matched against the
short names for each topic, and not the header. So
hg help 'Environment Variables'
must be replaced with
hg help env
Besides updating the tests output, I had to push back at the end the test for
issue1193 in test-commit, solved by cset 31a0a36d6d95, because it was using the
current date for commit and was randomizing the subsequent hash.
The real reason for both issue is that bisect can not handle cases where there
are multiple possibilities for the result.
Example (from issue1228):
rev 0 -> good
rev 1 -> skipped
rev 2 -> skipped
rev 3 -> skipped
rev 4 -> bad
Note that this patch does not only fix the reported Assertion Error but also
the problem of a non converging bisect:
hg init
for i in `seq 3`; do echo $i > $i; hg add $i; hg ci -m$i; done
hg bisect -b 2
hg bisect -g 0
hg bisect -s
From this state on, you can:
a) mark as bad forever (non converging!)
b) mark as good to get an inconsistent state
c) skip for the Assertion Error
Minor description and code edits by pmezard.
add _checklink var to dirstate
introduce dirstate.flagfunc
switch users of util.execfunc/linkfunc to flagfunc
change manifestdict.set to take a flags string
change ctx.fileflags to ctx.flags
change gitmode func to a dict
remove util.execfunc/linkfunc
Using the term "the repository's working directory" instead of just "working
directory" to make it nearly impossible to confuse it with $PWD.
Also, this new wording better conveys the fact that update applies
to the working dir as a whole (no matter what the $PWD currently is).
When we're using copies() to find changes between the working directory and
its first parent for diff/status/etc., use dirstate.copies() directly.
This avoids doing a full statwalk for simple diffs (issue1090) and
removes a special case from the status command.
The helptable is used for helptopics listed in the manual
page, so the order of topics should not be random.
Convert it from a dictionary into a tuple of tuples.
Also reorder helptable entries to keep previous manual
page order.
Instead of giving the "command %s is ambiguous" error message
with a bare list of possible command, display help list
for all commands starting with the given string.
Backing out a changeset that is before a named branch branchpoint was
making the reverse changeset the tip of the old branch, which is wrong
and very confusing. So instead, we put it on the current named branch.
- complain about attempts to merge with ancestor
- when updating, differentiate between
- crossing named branches with no local changes (jump)
- crossing named branches with local changes (complain)
- nonlinear update on the same named branch, no changes (complain some more)
- nonlinear update on the same named branch, changes (different complaining)
In an extreme case (merging two revisions with very low revision numbers)
this could be slower than the previous code, but it should be much faster
in the usual cases (parents are near the tip). It also avoids some races
in some uninteresting cases (e.g. two concurrent hg commits).
- Added files are never deleted (only removed with --force).
- Modified files can only be removed with --force.
- With --after, only deleted files are removed.
- With --after --force, all files are removed but not deleted.
- Example: "hg tag -r 42 build-25 beta-1" will add tags build-25 and beta-1
for rev 42.
- The deprecated and undocumented usage "hg tag arg1 arg2" used to emit a
warning, then add tag arg1 for rev arg2 (equivalent to "hg tag -r arg2 arg1").
It will now add tags arg1 and arg2 for the current revision.
- If one tag triggers an error, no tags are added/removed (all or nothing).
This can make a difference when there are filters involved and
decode(encode(working-dir-data)) != working-dir-data
even though
encode(decode(repo-data)) == repo-data
An example is a working dir file that uses only \n when you're using
the win32text extension.
The error message at startup when the address/port could not be bound
was confusing:
hg serve
abort: cannot start server: Address already in use
Be more explicit:
$ hg serve -a localhost
abort: cannot start server at 'localhost:8000': Address already in use
Also be more explicit on success, showing hostname and ip address/port:
$ hg -v serve -a localhost -p 80
listening at http://localhost/ (127.0.0.1:80)
We are careful to handle a missconfigured machine whose hostname does not
resolve, falling back to the address given at the command line.
Remove a dead-code error message.
The '-q' flag was ignored in status command. But this flag
can be used to hide non-tracked files in hg status output.
This small correction makes status command more general,
similar to 'svn status', where '-q' flag has the same effect.
The '-u' and '-A' flags have priority over '-q'.
A testcase and doc-string for status was extended to cover
'-q' flag.
Currently, backout is creating a backout revision as a child node of the
backed out node and will leave you at this new head. This has several
drawbacks:
* this changes the current head
* when there is a long history between the backed out node and the
current head, this will generate a huge number of diffs that are scary
at first sight, and not very natural to review before commit.
The change consists to switch back to the original node as soon as the
backout node (which becomes the new tip) has been created. Then the
--merge option can just merge this new tip in the current node.
* the current head/node is not changed from the user's point of view
* even without using the --merge option, the backout revision is still
easy to locate, as this is the tip
* the merge is much more intuitive as diffs of the merge is right you
are looking to backout
In the kernel repo (tip = 2b89f7111b96), a "hg grep mpm MAINTAINERS" goes
from ~165s to 0.7s. This could get even a bit faster if we broke out of
the loop after the first match, but I'm not sure how that would interact
with the --follow code.
This is obviously an extreme example, but other cases should also benefit
from this patch.
commit (aborts _after_ typing in a commit message)
backout (aborted after the initial revert)
tag (edited .hgtags and couldn't commit)
import (patch applied, then commit fails)
qnew (aborts on bad dates, but writes any valid date into the # Date header)
qrefresh (like qnew)
sign (like tag)
fetch (merge, merge, merge, merge, abort)
This doesn't make a difference right now, but after the next revision
some files in state 'a' may end up in the deleted list, and revert
won't be able to just remove all files in that list.
commands.revert calculates everything that has to be done and then
calls hg.revert to checkout and remove files. Unfortunately,
hg.revert has to recalculate everything and that can take a long
while, since it always operates on the whole working dir.
Changing commands.revert to manually checkout and remove files
makes things considerably faster, especially if we're reverting
a single file in a repo with a huge number of files.
This should be enough to close issue857.
- hg archive --no-decode has no short option, too, and maybe both could use
-d in the future to select revisions by date.
- opts.get makes python scripts calling cat() happy, because they don't have
to pass the new option.
That's just an artifact of the current implementation, and I'll change
that soon.
Bonus points:
- we don't care about the unknown list at all
- we don't print an extra message if we try to revert a removed file
that is not present in the target revision
Add [merge-tool] hgrc section with:
<tool>.executable = name or path (<tool>)
<tool>.args = args with $local/base/other/output ($local $base $other)
<tool>.priority = priority (default 0)
<tool>.binary = handles binary (False)
<tool>.symlink = handles symlinks (False)
<tool>.checkconflict = check for conflict markers (False)
<tool>.premerge = try internal simplemerge (True if not binary or symlink)
Four built-in tools: internal:{merge,local,other,fail}
Add [merge-patterns] section of the form:
<pattern> = <tool>
Priority of settings is:
HGMERGE
merge-patterns
ui:merge
merge-tools by priority
hgmerge, if it can be found
Changes:
unsuccessful merges leave .orig files
The prose section of the help text for the command already said that -u and -m
are accepted, but -u was not listed in the table of options, and did not work.
Useful when accepting patches from other people made by hg diff rather than hg
export. For completeness, also accepting -d DATE.
[CHANGES: rebased against 2f0da487820f, --no-commit option.]
If copy logged in file revision, we report copy for changeset only
if file revisions linkrev points back to the changeset in question
or both changeset parents contain different file revisions.
This fixes extra copies reported when executable bit was changed for
previously copied file.
Automatically detect whether we're looking for a bad to good
transition rather than the usual good to bad transition by detecting
when badrev is inside the good set and flipping good/bad.
