- 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
