Maybe beginners tend to use 'hg branch EXISTING_BRANCH' instead of
'hg update EXISTING_BRANCH' as me.
If so, let's help them to use 'update'.
Also removed '(use --force to override)' because it can mislead them.
Since 461b5218840e annotate follows copies/renames by default, but the output
of e.g. "annotate --follow --number" should not change without some
deprecation time.
__doc__ of aliased command shouldn't cointain non-ASCII characters,
because it'll be gettext-ed later by commands.help_().
Here gettext can raise UnicodeDecodeError.
Once concatenated two translatable strings into one, it become untranslatable.
So this patch moves 'alias for:' from dispatch.cmdalias to commands.help_,
where help texts are translated.
'alias for:' was introduced by 027d5c280eda.
Formerly, it omitted nodes that were not descendants of the least
common ancestor of the two merge parents, even though those nodes
contribute to the merge. The new algorithm uses revlog.findmissing()
instead of ancestor() + nodesbetween().
Previously, the name part of an repo#name url was interpreted as a
revision, similar to using the --rev option. Now it is instead looked
up as a branch first, and if that succeeds all the heads of the branch
will be processed instead of just its tip-most head. If the branch
lookup fails, it will be assumed to be an revision as before (e.g. for
tags).
Before a command is declared unknown, each extension in hgext is searched,
starting with hgext.<cmdname>. If there's a matching command, a help message
suggests the appropriate extension and how to enable it.
Every extension could potentially be imported, but for cases like rebase,
relink, etc. only one extension is imported.
For the case of "hg help disabledext", if the extension is in hgext, the
extension description is read and a similar help suggestion is printed.
No extension import occurs.
repo.branchtags().keys() are in UTF-8, so the label should be converted to UTF-8
before checking for a naming conflict. Keep the original label for ui.status()
'hg summary' recognizes workdir as clean by searching for 'clean' is
in own output text. But 'clean' is one of I18N target texts, so 'hg
summary --quiet' behaves incorrectly in non-English locale.
The literal blocks were mis-used for alignment, but this of course
changes the font of the entire block to a fixed width font in the HTML
version. Using a proper list solves this.
This fixes an incompatibility with patch(1), which also uses --reverse
for reversed diffs. The --inverse flag was added in 0f0383897d54. That
name was chosen over --reverse since it was thought that --reverse
would make --rev ambiguous.
It turns out that both flags can co-exist, with the cost that --rev
can no longer be shortened to --r and --re. Since one can always use
the short -r option, this is not a real problem.
Most of the time, one can reverse a diff by swapping the revisions passed with
-r but it happens that if you use the global -R, and diff against the tip of
the current repo, you can't swap the revisions. One use-case for that is
reviewing changes from a bundle before unbundling. One could also pipe the
output of `hg diff` to a command line filter that reverses the diff, but that
would remove the benefit from color diffs. Therefore, having an option in
`hg diff` to reverse a diff is a good thing.
The option flag selection was tricky. GNU patch uses -R/--reverse but -R is
already used as a global option and --reverse would make --rev ambiguous.
Normally, diffs without any text insertions or deletions are reported
as having 0 lines changed by stock diffstat. Compatibility is
preserved with stock diffstat in this case, but when using --git,
binary files are marked with Bin as a means of clarification.
git diff --stat does something similar, though it also includes the
old and new file sizes.
diff/qdiff --stat invokes patch.diffstat() on the diff output.
When in interactive mode, the output's maximum width is determined by the
terminal's width.
The existing scheme using util.find_exe and subprocess.call meant we
couldn't use simple shell commands in tests. Fix that.
Also, it mistakenly used status from the system() call rather than
good from the bisect call in reporting results.
The help topics are reused in the HTML documentation, and there it
looks odd that whole sections are indented. We now only indent it for
output on the terminal.
Splitting the string after translation relies on the implicit
assumption that translators will always translate the English words
using single foreign words.
Also, when translating we want as much context as possible so I've
moved the string formatting into the translatable string.
It is not very helpful to have 'Added tag %s for changeset %s' and
similar messages translated into different languages when people work
together using different locales.
We now use English strings without support for translations. If
needed, the user can still supply a custom string for most commands.
It is no longer necessary to wrap the docstrings at 70 characters in
the source -- with the reST parser, they are re-formatted to fit the
terminal when shown.
However, wrapping the docstrings at 78 characters makes life harder
for translators because it marks a lot of strings as fuzzy for no good
reason. When un-marking them, the translators would have to examine
each string again and determine if it is merely re-wrapped or if the
content was also changed.
The long lines also introduce very ugly linebreaks in the .po files if
they are processed using the standard Gettext tools without using
something like '--width 85' all the time.
We have always had a left margin of 4 characters -- probably just
because that's how docstrings for top-level functions turn out by
default, but it also looks nice in the built-in help.
The docstrings were wrapped at 70 characters, which is the default for
Emacs. However, this gives a right margin of 10 characters in a
standard 80 character terminal.
I've now wrapped the relevant docstrings at 78 characters, effectively
killing the right margin. The asymmetric margins looked a bit odd and
some of the text looked cramped with a right margin, so Dirkjan and I
felt that it was best to remove it entirely. The two character gap was
kept to have some space between the border of the terminal -- it will
also make diffs involving the docstrings fit in a 80 character line.
The code for wrapping a single line of text with a hanging indent was
duplicated in commands and help -- it's now moved to a new function
called wrap in util.
The function defaults to a line width is 78 chars, and this un-wraps
some command line flag descriptions, hence the test output changes.
I found that typical case is that grep target is added at (*) revision
in the tree shown below.
+--- 1(*) --- 3
0
+--- 2 ------ 4
Now, I expect 'hg grep --all' to show only rev:1 which is first
appearance of target line.
But 'hg grep --all' will tell:
target line dis-appeared at 3 => 4
target line appeared at 2 => 3
target line dis-appeared at 1 => 2
target line appeared at 0 => 1
because current 'hg grep' implementation compares not between target
revision and its parent, but between neighbor revisions in walkthrough
order.
I checked performance of this patch by "hg grep --follow --all
walkchangerevs" on whole Mercurial repo, and patched version could
complete as fast as un-patched one.
The intent is to fix many issues involving patching when win32ext is enabled.
With win32ext, the working directory and repository files EOLs are not the same
which means that patches made on a non-win32ext host do not apply cleanly
because of EOLs discrepancies. A theorically correct approach would be
transform either the patched file or the patch content with the
encoding/decoding filters used by win32ext. This solution is tricky to
implement and invasive, instead we prefer to address the win32ext case, by
offering a way to ignore input EOLs when patching and rewriting them when
saving the patched result.
- repository heads are not associated with the closed attribute, so
remove it making the code in line with the concept.
- Fix functions that were calling heads with the parameter.
- Adjust webcommands.branches to include the concept of inactive
as well as open and closed branches
- Fix code and docstrings in commands to make the correct use of
closed branches & branch heads clearer
- Improve grammar of 'hg heads' help text (2nd submission)
this does not alter the cli for hg branches, that work is
still to be done
Add a --closed (-c) option to 'hg heads' to show all heads and change the
default behavior to refrain from showing fully closed branches.
Enhance 'hg heads <branch>' so that:
* default: displays normal & inactive heads, not closed heads
* --closed: displays normal, inactive & closed heads
* --active: displays only normal heads
* both --closed and --active: displays normal & closed heads only
This error trigger if one calls bundle with the wrong parameters and
it is thus not an error scripts will want to look for (they could and
should ensure that they call bundle with the correct parameters).
This command does exactly what 'hg remove -Af [FILES]' does.
The reason for creating a new command is that the options for 'hg remove'
are confusing (-A removes only deleted files, -f forces deletion, and using
both means *the exact opposite of both*).
[mpm: simplified help text, code, and updated tests]
Semantically, it is better to use None over any other value when there is
"no value". Using maxint in this context is quite hackish, and is not forward
compatible.
{file_copies} template now displays file copies with or without the --copies
switch being set. A new {file_copies_switch} template implements the former
behaviour.
This option is similar to the one already used for the diff command.
Unfortunately, the c and C short option are already used for status, so there
is no corresponding short option. However, there is no short option for --rev
either, so that's consistent.
Some of the descriptions of command line options were getting quite
long, and when translated they are likely to grow even longer. This
word-wraps them at 70 characters, just like the help texts.
We could have opted to wrap them at the terminal width instead, but I
think it looks better to have them be consistent with the help texts.
hotshot was an experimental module, which is broken for Python < 2.5
And even for Python >= 2.5 users, hotshot usage is discouraged: cProfile
(formerly lsprof) should be used instead.
