As tags may have embedded spaces, and "hg tags" command doesn't escape them,
the output of the command doesn't make a well-formed list, so we can't just
iterate over it. Instead, apply a simple regexp to transform it to a list
which we actually use. Line boundary matching should be enabled.
Previously, _hg_shelves used the unshelve command to list current shelves. This
is actually the wrong command. The correct usage is 'hg shelve -l' so we use
that instead.
Previously, if there was a directory between the file and first-level directory (e.g. 'bar' in
foo/bar/file), then bash_completion would only list 'foo/file' instead of 'foo/bar/file'.
This behavior was introduced in ed00ea08afda to fix spaces in file names. In
this patch, we keep that behavior while also fixing subdirectory completion by
reverting ed00ea08afda and instead add backslashes to whitespace manually. This
approach means adding the completion option 'nospace' since we do this manually
now.
This solves an issue for users that have "alias hg='hg --some_opts'" where they
would see wrong entries in the completion output (such as color codes).
The code adding the prefix is now run once per pattern. It was run once per
file (after the change 17484f4c54fb).
Demonstrate that it is working now by extending the test. Raise two different
warnings, one of them twice.
This makes sure that all cycles begin with the lexicographically first
module, so that we're less likely to show overlapping cycles in the
final analysis.
This checks for cycles in the module graph and verifies that imports
of stdlib modules are not on the same line as relative imports of
mercurial modules.
This is a step towards breaking an import cycle between revset and
repoview. Import cycles happened to work in Python 2 with implicit
relative imports, but breaks on Python 3 when we start using explicit
relative imports via 2to3 rewrite rules.
Adds a script that opens the editor to the conflict as part of the merge
process. This way you can fix the merge during the rebase instead of having to
pause the rebase, resolve --mark, rebase --continue.
Only works on unix.
Because string entries are replaced before matching, we must search for
the transformed pattern. But it seems to be quite unique and does not return
false matches. If it will, they can be listed as 3rd arg in pypats.
When a warning occured several times in one file, "warning: " was prepended
several times:
examplefile.py:3:
> def a(object):
warning: this looks wrong
examplefile.py:27:
> def x(object):
warning: warning: this looks wrong
This style of import can trip up 2to3 and cause it to produce invalid
files if one of the imports is supposed to be a relative import. This
prevents that behavior, and in the process exposed a lot of silly
import errors related to the email module.
The -a option to GNU grep isn't available when using Solaris grep. Replace
the one use of grep -a in the testsuite with some in-line Python that does
the equivalent, and add a check for grep -a in check-code.py.
Some warnings had "warning: " at the beginning of their message. Now this
is done consistent for all messages.
Especially in test-check-code-hg.t it is an advantage to see warnings at once
because only exceptions to them are tolerated. It is (almost) as obvious as
before a6180647ea.
The prefix will not remain when a warning is changed to a failure. A change
like a91387a37f will not be necessary anymore.
The python compiler concatenates two string constants. Use this instead of
doing it on run time or instruct the user how to do it.
The strings "no-check-code" and "check-code-ignore" has to be specially written
for not skipping some checking of the code of this file.
When there is a double backslash the following char does not have any special
meaning. So do not warn on this.
Remove the now obsolete no-check-code statement. (It was used wrongly anyway, it
skipped checking the entire file.)
The annotate algorithm used a custom parents() function to try to reuse
filectx and filelogs. I simplified it a bit to rely more heavily on the
self.parents() which makes it work well with alternative filectx
implementations. I tested performance on a file with 5000+ revisions
but no renames, and on a file with 500 revisions repeating a series of
4 edits+renames and saw zero performance hit. In fact, it was reliably a
couple milliseconds faster now.
Added the perfannotate command to contrib/perf.py for future use.
Create a simple start() method to pass the lookup function until bundler
becomes smarter and gets a repo object.
Since we now create the bundler for the whole lifetime, we need to pass it
down to revlog methods.
Before this patch, "hg.bat" for Windows environment always uses
"%~dp0..\python" as explicit path to "python.exe".
This path may not be valid in some cases.
For example, on the environment using "virtualenv" python package,
both "python.exe" and "hg.bat" are placed in the same directory. In
this case, "python.exe" should be found on PATH, because virtualenv
activation script puts "python.exe" on the PATH.
This patch uses explicit path to "python.exe" only if it exists, and
expects that "python.exe" can be found on PATH otherwise.
The regular expression was meant to match cases where an 'i' command was
not followed by precisely a '\' and then a newline; it failed to match
the newline, so cases with a '\' but no newline would erroneously pass.
Expands the rule added in a3f00ef2b622 to include cases where the
address is a line number instead of a regular expression, and fixes an
instance of this pattern in test-unionrepo.t.
BSD sed requires the 'i' command to be followed with a backslash and a
newline, like so:
$ sed -e '/^@/i\
> other'
We've encountered this problem before, e.g. in test-mq.t (215a8789129e).
This change adds a check-code rule and fixes two instances of the
problem in test-record.t.
Up until now commit/backout `--logfile` option was completed only with
*.txt-files. This requirement is a bit too strong (and is nowhere to be stated)
so it's better to complete with all files.
Stolen from zsh.git repo, c5fce37b changeset by Oliver Kiddle.
Add -o $output.
When using Meld as intended (merge from left and right into the center panel),
the merged version is written to the wrong file without this option ($base,
a temporary file, which is ignored by Mercurial).
Add meld.check=changed as a secondary safety net.
Use `debuglabelcomplete` command when populating labels list, instead of
calling `hg` three times: for branches, bookmarks and tags. Do not pass string
being completed to `hg debuglabelcomplete` (as `$words[$CURRENT]`), since it
breaks `_hg_revrange` completion (`--rev 2.5:2.5.<Tab>`) for no apparent
benefit.
Also complete `hg view` with labels, not just tags, and drop unused `_hg_tags`.
As suggested by mpm reintroducing this test failure on windows is
prevented by a code-check. One line in a unix test is ignored.
This pattern matches 20 windows glob lines.
We explicitly redraw before echoing the message so that it simply
displays at the bottom of the window. Also simplifies the message
printing by using 'echomsg' (which uses 'echohl' internally) and adds
the names of the software involved for improved Googleability.
Adds a message displayed at each vimdiff invocation:
merge conflict detected, type ":cq" to abort
Vimdiff is very confusing for non-vim user (not to speak about vim user confused
anyway. However it is very likely that vimdiff is picked as the mergetool of
choice when using the default config:
- vim is available on all UNIX system.
- Its one of the rare non graphical merge tools.
It seems like the API has changed somewhere around 8.5.7, so the preferred way
of getting the current theme is now [ttk::style theme use], while the
deprecated (but still working) is $::ttk::currentTheme.
As when hg tags is being called without -v option, it returns
lines with two elements in each, we can just interate them as
if it were a usual Tcl list using foreach and two variables.
Line endings and whitespace don't matter when doing so, so we
may keep them as is.
When we're processing the lines, tag variable is assigned a tag
name, and rev is a string in form of revision:hash which we can
split on colon. As Tcl8.4 lacks lassign command, and using lindex
makes code a bit less readable, we use foreach to iterate over
two-element list.
Replace labels with window titles.
That also requires to change grid placement manager settings
to compensate padding which used to be applied to now non-existent
labels.
Ttk doesn't automatically set up Tk colour palette.
Because of that, Ttk controls look differently when used
together with old Tk controls. When we use Ttk controls,
we first query if we have any setting for the client
background, and if we do, we update Tk palette as well.
The current bash_completion code can be very slow in a large working
directory. It always uses "hg status" to generate possibly matching
files, which checks the status of every file. We often don't care
about status when completing, so that cost is very high.
As the new debugpathcomplete command does not check the status of
files, it offers much better performance for commands that only
care about completing names.
When completing a "label" (a symbolic name for a commit), the
bash_completion script currently has to invoke hg three times. For
a large repository, the cost of starting up and loading all the
necessary context over and over is very high.
For instance, in mozilla-central:
time (export HGPLAIN=1; hg tags -q; hg bookmarks -q; hg branches) >/dev/null
0.446 sec
Compare with the debuglabelcomplete command that this commit adds:
time hg debuglabelcomplete >/dev/null
0.148 sec
This greatly helps responsiveness.
Previously, we only completed files that had already been manually
deleted. That behaviour made no sense. We now complete unmodified,
modified, and deleted files.
This greatly helps completion performance for most commands that deal
with files.
In a working dir with 150,000 files, where we want to complete the name
of a modified file under a path beginning with "a", from the root of
the working dir:
(old) hg status -nm . 1.7 sec
(new) hg status -nm "glob:a**" 0.3
Even "hg add" becomes a little faster, in spite of being the worst
case (matching untracked files).
We explicitly redraw before echoing the message so that it simply
displays at the bottom of the window. Also simplifies the message
printing by using 'echomsg' (which uses 'echohl' internally) and adds
the names of the software involved for improved Googleability.
Adds a message displayed at each vimdiff invocation:
merge conflict detected, type ":cq" to abort
Vimdiff is very confusing for non-vim user (not to speak about vim user confused
anyway. However it is very likely that vimdiff is picked as the mergetool of
choice when using the default config:
- vim is available on all UNIX system.
- Its one of the rare non graphical merge tools.
We have a bunch of tests that still use
kill `cat hg.pid`
or worse,
kill `cat hg.pid`; while kill -0 `cat hg.pid`; sleep 0; done
Cleaning these up to use tests/killdaemons.py is non-trivial, so for now
we just add a warning.
These settings were replaced by check=changed and check=conflicts in
9b0e7e973592. There is no reason to announce two different ways to achieve the
same. The old way should be kept but not announced.
This also makes the perfancestorset command use lazy membership testing. In a
linear repository with over 400,000 commits, without this patch, hg
perfancestorset takes 0.80 seconds no matter how far behind we're looking.
With this patch, hg perfancestorset -- X takes:
Rev X Time
-1 0.00s
-4000 0.01s
-20000 0.04s
-80000 0.17s
-200000 0.43s
-300000 0.69s
0 0.88s
Thus, for revisions close to tip, we're up to several orders of magnitude
faster. At 0 we're around 10% slower.
The new command, perfancestorset, takes an argument denoting which revset to
test the membership of.
Currently this runs through all the ancestors and converts them into a set.
The primary purpose of having this is to compare this approach, currently used
in several places, against the upcoming lazy approach.
New warnings:
> a.b=ab
missing whitespace in assignment
(the pattern did not accept '.' on the left hand side)
> a=a
missing whitespace in assignment
(the right hand side pattern never matched a single character)
> a=a + 7
missing whitespace in assignment
(the pattern only matched one character after the identifier following =)
The check pattern only checked for whitespace between keyword and operator.
Now it also warns:
> x = f(),7
missing whitespace after ,
> x = f()+7
missing whitespace in expression
When status needs to look at unknown files (e.g. when running hg status), it
needs to use a completely different algorithm than when it doesn't (e.g. when
running hg diff).
This makes sure that .hg/requires is observed and the correct kind of store
object is created. Otherwise we might mutilate our test repos when experimenting
with new repo formats.
