Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 21:26:53 -0800] rev 24088
webcommands: document "file" web command
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 21:13:03 -0800] rev 24087
webcommands: document "log" web command
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 20:50:17 -0800] rev 24086
webcommands: document "shortlog" web command
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 20:48:22 -0800] rev 24085
webcommands: document "changeset" web command
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 20:44:46 -0800] rev 24084
webcommands: document "tags" web command
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 20:43:54 -0800] rev 24083
webcommands: document "bookmarks" web command
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 20:44:10 -0800] rev 24082
webcommands: document "branches" web command
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 20:41:08 -0800] rev 24081
webcommands: document "help" web command
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 20:27:56 -0800] rev 24080
help: add web commands to help documentation
The capabilities and URL endpoints of the hgweb server can currently
only be inferred by looking at links in `hg serve` output or by reading
the source code. I've frequently found myself wanting to quickly see
what URLs and capabilities are available.
This patch teaches the help system how to display information about
web commands and their URLs. Using a mechanism similar to revsets,
templates, etc, we can now iterate over the docstrings of registered
web command functions and display them in the help output.
Unfortunately, web commands don't currently have docstrings, so the
output is currently empty. This will be addressed in the following
patches. I apologize for the patch bomb.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 23:08:47 -0800] rev 24079
help.hgweb: add a section describing URLs and common parameters
The behavior of hgweb's URLs isn't documented anywhere inside Mercurial.
Let's start to change that.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 22:47:48 -0800] rev 24078
webcommands: move help import into help command handler
A subsequent patch will introduce an import cycle between mercurial.help
and mercurial.hgweb.webcommands. Break the cycle by moving the import of
mercurial.help into the web command that actually needs it.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 22:52:40 -0800] rev 24077
webcommands: define a dict of available commands
This will be used to hook web commands up to the help system. It also
makes web commands work similarly as CLI commands.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 19:06:17 -0800] rev 24076
webcommands: define web commands using a decorator
Other parts of Mercurial have evolved to use decorators to declare
commands or handlers. This patch gives the same treatment to web
commands.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 16:33:05 -0800] rev 24075
run-tests: ensure install directories exist
As part of the transition to setuptools, it was discovered that
setuptools doesn't create install directories for you where distutils
apparently did. This was causing run-tests.py to fail when creating the
temporary hg install.
We work around this problem by creating the install directories before
running setup.py.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 16:15:02 -0800] rev 24074
run-tests: avoid printing extra newlines from install log
If an installation error occurs, we print the install log. Before,
output had extra newlines because we were using "print" on data that was
already newline terminated.
Eric Sumner <ericsumner@fb.com> [Fri, 06 Feb 2015 11:27:25 -0800] rev 24073
bundlerepo: basic bundle2 support
For bundlerepo to work with bundle2 files, we need to find the part that
contains the bundle's changegroup data and work with that instead of the
entire bundle. Future work can add separate processing for other bundle2
parts.
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 16:03:26 -0800] rev 24072
bundlerepo: keep track of the original bundle object
Bundlerepo should always close() the object that it receives from
exchange.readbundle(). When bundle2 support is added in a later diff,
self.bundle will be overwritten to be the changegroup part instead of the
entire bundle unpacker.
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 15:56:50 -0800] rev 24071
bundle2.unbundle20: add compressed() method
Bundlerepo uses the compressed() method to determine whether it should write
an uncompressed temporary file. Since we don't support compressed bundle2 files
at the moment, make this method return true.
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 15:52:57 -0800] rev 24070
bundle2.unpackermixin: default value for seek() whence parameter
The contract for seek() includes seeking to an offset from the beginning of the
file when whence is omitted; put this implementation in compliance.
Adrian Buehlmann <adrian@cadifra.com> [Fri, 06 Feb 2015 23:40:46 +0100] rev 24069
windows: adjust doc string and comments of posixfile()
The doc string of osutil.posixfile includes (line 611):
"On error, this function may raise either a WindowsError or an IOError."
which is most likely correct, but does not fit for this function here anymore,
as we do fold WindowsError to IOError here specifically.
And this function is now a bit more than just an exception-wrapper, as it has
been expanded to additionally sanitize the unloved seek/tell behavior
of Windows.
(Self-disclosure: This patch is entirely untested at the time of its
publication, as I'm currently not using this version myself. I send it
in hopes that it will reduce potential future confusion. CC-ing Matt Harbison)
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 04 Feb 2015 14:11:45 -0800] rev 24068
color: support a different color mode when the pager is active
MSYS on Windows has a terminal that supports the "win32" color mode
(which "auto" properly detects for us). However, a popularily configured
pager in that environment (GNU less) only supports the "ansi" color
mode.
This patch teaches color about a new config option: pagermode. It
behaves like "mode" but is only consulted when the pager is active for
the current command. MSYS users can now set "pagermode = ansi" and get a
colorful experience that just works. Previously, MSYS users would have
to live without color when using GNU less as the pager, would have to
manually configure the pager to attend every command, or would have
gibberish if "ansi" was used without the pager.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:09:09 -0800] rev 24067
pager: ensure wrapped dispatch._runcommand runs before color's
An upcoming patch will teach color to potentially act differently if the
pager is active. Since both extensions wrap the same function
(dispatch._runcommand) to change behavior, we must guarantee that
pager's wrapped function runs before color's so color may read the
breadcrumb left by pager.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:07:56 -0800] rev 24066
pager: set an attribute on ui indicating that a pager is active
A subsequent patch will teach the color extension to do different things
depending on whether a pager is active. This patch leaves a breadcrumb
on the ui instance to allow it do that that.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 06 Feb 2015 12:07:32 -0800] rev 24065
extensions: support callbacks after another extension loads
An upcoming patch will introduce a dependency between the color and
pager extensions. To prepare for this, we teach extensions how to
register callbacks that can execute when another extension loads.
This patch is based on code provided by Matt Mackall. But significant
parts have changed (such as the ability to register multiple callbacks
and the change in behavior to always call a callback).
I believe that always firing the callback is a good practice. I think
the common use for this feature will be for extensions to say "run this
one-time setup code, after this other extension if possible." Always
running the callback will facilitate this.
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Feb 2015 21:53:39 +0900] rev 24064
log: fix --follow null parent not to include revision 0
If p1 is null, ':.' is translated as '0:null'. But rangeset can't handle null,
only revision 0 was visible. Because 'null' should not be listed implicitly,
"log --follow" (without -r) should be empty if p1 is null.
Test of "hg grep -f" is added for cmdutil.walkchangerevs().
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Feb 2015 00:22:20 +0900] rev 24063
cmdutil: have walkchangerevs utilize common function to build revs
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Feb 2015 00:15:35 +0900] rev 24062
log: extract common part from getgraphlogrevs() and getlogrevs()
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Feb 2015 00:06:47 +0900] rev 24061
graphlog: remove useless check for empty repo when --follow is specified
This prepares for extracting common part from getgraphlogrevs() and
getlogrevs(). getlogrevs() does not handle empty repo specially.
When it was added at d74099ac2ac1, revs were build by old-style query, '.:0'.
So I think the purpose of "len(repo) > 0" was to handle the case of . = null.
Currently it isn't necessary for 'reverse(:.)', and it does not work if repo
is not empty but p1 is null.
$ hg up null
$ hg glog --follow -T '{rev}:{node|short}\n'
o 0:0a04b987be5a
The subsequent patch will fix this problem, so drops the wrong version for now.
Yuya Nishihara <yuya@tcha.org> [Thu, 05 Feb 2015 23:49:18 +0900] rev 24060
graphlog: move comment and flag denoting revs might be unsorted
This prepares for extracting common part from getgraphlogrevs() and
getlogrevs(). "possiblyunsorted" exists only in getgraphlogrevs().
Yuya Nishihara <yuya@tcha.org> [Thu, 05 Feb 2015 23:14:44 +0900] rev 24059
graphlog: remove too early return from getgraphlogrevs() for empty repo
Even if repository is empty, null revision should exist.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jan 2015 22:22:09 -0800] rev 24058
trydiff: call util.binary in only one place
It's practically free to call util.binary on empty or None content. By
relying on that, we can replace the current four call sites by one.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jan 2015 21:35:57 -0800] rev 24057
trydiff: collect all lossiness checks in one place
By having all the checks for lossiness in one place, it becomes much
easier to get an overview of the conditions that lead to losedatafn()
being called. It also makes it obvious that it can not be called
multiple times for a single time (something that was rather tricky to
determine before).
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jan 2015 21:03:57 -0800] rev 24056
trydiff: replace 'binarydiff' variable by 'binary' variable
It's not obvious, but every path in the 'if opts.git or losedatafn:'
block will have checked whether the file is binary [1]. Let's assign
the result of this check to a variable so we can simplify by checking
'binary and opts.git' in only one place instead of every place we
currently assign to 'binarydiff'.
[1] Except when deleting an empty file, but checking whether an empty
string is binary is very cheap anyway.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:09:21 -0800] rev 24055
trydiff: rename 'op' to make it more specific
Rename the 'op' variable that can take values None/'copy'/'rename' to
'copyop' to make it a little more specific.
Anton Shestakov <engored@ya.ru> [Fri, 06 Feb 2015 15:52:55 +0800] rev 24054
hgweb: replace implicit <tbody> with explicit <thead> where appropriate
Some templates in paper style use <tbody> elements inside <table> to assign a
class to "body" part of that table (in this case, to make rows striped). The
problem is that the <tbody> is preceded by <tr> element, which browsers
understand as an implicit start of table body, so the following exlicit <tbody>
will actually be "nested", which is not valid.
Since that first <tr> contains table headers, wrapping it in <thead> is both
semantically correct and follows the advertised XHTML 1.1 doctype.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Jan 2015 12:54:35 -0500] rev 24053
obsolete: drop the explicit seek to EOF after append mode open()
posixfile now handles this.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Jan 2015 12:42:05 -0500] rev 24052
branchmap: backout 6bf93440a717
This is no longer needed now that posixfile handles seeking to EOF when it opens
a file in append mode.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Jan 2015 12:39:44 -0500] rev 24051
windows: seek to the end of posixfile when opening in append mode
The position is implementation defined when opening in append mode,
and it seems like Linux sets it to EOF while Windows keeps it at zero.
This has caused problems in the past when a file is opened and tell()
is immediately called, such as 48c232873a54 and 6bf93440a717.
Since the only caller of osutil.posixfile is this windows module, this seems
like a better place to fix the issue than in osutil.c and pure.osutil.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Nov 2014 12:15:12 -0800] rev 24050
context: use unfiltered repo for '.'
There is no reason to read obsolescence markers when doing a plain 'hg
status' without --rev. Use the unfiltered repo when initializing
context._rev to speed things up. This speeds up 'hg status' from
1.342s to 0.080s on my repo with ~110k markers.
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 14:09:08 -0800] rev 24049
check-commit: check capitalization in summary lines
At the moment, check-commit will complain about the topic being capitalized,
but not the summary that comes after it. This diff corrects that deficiency.
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 10:57:45 -0800] rev 24048
bundle2: seek in part iterator
When iterating over bundle2 parts, add a seek to the iterator so that
processing will continue normally even if the entire part isn't
consumed.
Eric Sumner <ericsumner@fb.com> [Thu, 05 Feb 2015 10:56:05 -0800] rev 24047
bundle2: now that we have a seek implementation, use it
Replace bare part.read() calls with part.seek(0, 2) since the return value is
being ignored. As this doesn't necessarily require building a string that
contains the rest of the part, the potential exists to reduce the memory
footprint of these operations.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 04 Feb 2015 22:25:35 -0800] rev 24046
obsolete: populate successors, precursors, children lazily
The precursors and children dictionaries are not used by many
commands. By making them lazily populated,
'hg log -r @~10::@ >/dev/null' is sped up from 0.564s to 0.440s on my
hg.hg repo with 73k markers.
Also make successors lazily populated, mostly for consistency with the
others.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 04 Feb 2015 22:40:48 -0800] rev 24045
obsolete: pass only new markers to _checkinvalidmarkers()
We will soon delay populating precursors until we have to. To prepare
for that, make _checkinvalidmarkers() scan for a nullid precursor in
the list of new markers instead of the (currently) cheaper 'if nullid
in precursors' check.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 20 Jan 2015 22:01:37 -0800] rev 24044
obsolete: extract helpers from _load()
In preparation for making the successors, precursors, and children
dictionaries lazily populated, break up _load() into one function for
adding markers to each dictionary.
Eric Sumner <ericsumner@fb.com> [Tue, 20 Jan 2015 17:38:42 -0800] rev 24043
test-gendoc: require gettext
If the gettext utilities aren't installed, there is no way to make the
translations. This causes the gettext client to fall back to the untranslated
message, which triggers "** NOTHING TRANSLATED **" errors and a test failure.
Anton Shestakov <engored@ya.ru> [Thu, 05 Feb 2015 20:34:30 +0800] rev 24042
hgweb: use css margin instead of empty <p> before diffstat table
The <p> elements were used to create an empty space between the diffstat link
and the diffstat table, but they don't have any semantic meaning, so it is
better to use css instead.
Default margins for <p> elements can differ depending on the browser, but
usually the margin is 1em (exceptions are IE 6 and 7 with 14pt, which is
comparable). The css rule sets top margin to 1em.
This change is a "better version" of 70cfa7e1611b, where <p> elements were
simply properly closed.
Anton Shestakov <engored@ya.ru> [Thu, 05 Feb 2015 19:24:35 +0800] rev 24041
hgweb: use css margin instead of empty <p> before <div class="atom-logo">
The <p> elements were used to create an empty space between the last menu item
(i.e. "help") and the atom feed icon, but they don't have any semantic meaning,
so it is better to use css instead.
The css rule uses top margin of 10px, which is equal to the top margin of the
menu blocks ("help", "changeset, browse", etc). Previously, with <p> elements,
the margin wasn't set explicitly and was browser-dependent.
This change is a "better version" of 70cfa7e1611b, where <p> elements were
simply properly closed.
Augie Fackler <augie@google.com> [Mon, 26 Jan 2015 14:30:12 -0500] rev 24040
error: update docstring on ParseError
It's now used by revsets and filesets.
Augie Fackler <augie@google.com> [Mon, 26 Jan 2015 14:50:36 -0500] rev 24039
dispatch: consolidate formatting of ParseErrors
Martin von Zweigbergk <martinvonz@google.com> [Wed, 04 Feb 2015 13:57:35 -0800] rev 24038
error: store filename and message on LookupError for later
It may be useful to be able to get to the failed path and the
underlying error message when catching a LookupError, so let's make
them accessible.
Eric Sumner <ericsumner@fb.com> [Wed, 14 Jan 2015 16:14:19 -0800] rev 24037
bundle2.unbundlepart: implement seek()
This implements a seek() method for unbundlepart. This allows on-disk bundle2
parts to behave enough like files for bundlerepo to handle them. A future
patch will add support for bundlerepo to read the bundle2 files that are
written when the experimental.strip-bundle2-version config option is used.
Eric Sumner <ericsumner@fb.com> [Wed, 14 Jan 2015 15:57:57 -0800] rev 24036
bundle2.unbundlepart: tell() implementation
Keep track of how many bytes we've returned from read(); fairly straightforward.
Eric Sumner <ericsumner@fb.com> [Wed, 14 Jan 2015 14:46:23 -0800] rev 24035
bundle2.unbundlepart: keep an index of chunks and their locations
In order to make unbundlepart seekable, we need to keep a record of where the
chunks are so that we can go back to the correct point.
Eric Sumner <ericsumner@fb.com> [Wed, 14 Jan 2015 14:32:22 -0800] rev 24034
bundle2.unbundlepart: raise payloadchunks from a closure to a method
In a future patch, seek() will need to make a new chunk iterator for
the stream; this places it somewhere it can be called multiple times.
Durham Goode <durham@fb.com> [Fri, 23 Jan 2015 17:06:03 -0800] rev 24033
manifest: make lru size configurable
On machines with lots of ram, it's beneficial to increase the lru size of the
manifest cache. On a large repo, configuring the lru to be size 10 can shave a
large rebase (~12 commits) down from 95s to 70s.
Augie Fackler <augie@google.com> [Wed, 04 Feb 2015 11:38:30 -0500] rev 24032
parsers: use k instead of n for PyArg_ParseTuple because python 2.4 is awful
Yuya Nishihara <yuya@tcha.org> [Wed, 04 Feb 2015 21:37:06 +0900] rev 24031
revset: have rev() validate input by repo.changelog.__contains__()
fullreposet.__contains__() will be rewritten in order to support "null"
revision, and "rev()" won't be possible to rely on it.
This backs out eb763217152a, but there is no performance regression now.
revisions:
0) e1dbe0b215ae "l not in fullreposet(repo)"
1) this patch "l not in repo.changelog"
revset #0: rev(210000)
0) wall 0.000056 comb 0.000000 user 0.000000 sys 0.000000 (best of 48036)
1) wall 0.000049 comb 0.000000 user 0.000000 sys 0.000000 (best of 54969)
Yuya Nishihara <yuya@tcha.org> [Wed, 04 Feb 2015 21:25:57 +0900] rev 24030
revlog: add __contains__ for fast membership test
Because revlog implements __iter__, "rev in revlog" works but does silly O(n)
lookup unexpectedly. So it seems good to add fast version of __contains__.
This allows "rev in repo.changelog" in the next patch.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 02 Feb 2015 19:58:41 -0500] rev 24029
largefiles: set the extension as enabled locally after a clone requiring it
When cloning a repo that requires largefiles, the user had to either enable the
extension on the command line and then manually edit the local hgrc file after
the clone, or just enable it globally for the user. Since it is a feature of
last resort, and materially affects even repos without any largefiles when it is
enabled, we should make it easier to not have it enabled globally.
This simply adds the enabling statement to the local hgrc if the requires file
mandates its use (which only happens after the first largefile is committed).
That means that a user who works with a mix of largefile and normal repos can
always clone with '--config extensions.largefiles=', and the extension is
permanently enabled or not as appropriate.
The change in test-largefiles.t is simply because the order of loading rebase
and largefiles changed. The same change occurs if the order is flipped in the
hgrc file at the top of the test.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 03 Feb 2015 16:24:32 -0800] rev 24028
color: be more conservative about setting ANSI mode on Windows (BC)
The current color mode detection on Windows assumes the presence of the
TERM environment variable assumes ANSI is supported. However, this isn't
always true. In MSYS (commonly found as part of MinGW), TERM is set to
"cygwin" and the auto resolved color mode of "ansi" results in escape
sequences getting printed literally to the terminal. The output is
very difficult to read and results in a bad user experience. A
workaround is to activate the pager and have it attend all commands (GNU
less in MSYS can render ANSI terminal sequences properly).
In Cygwin, TERM is set to "xterm." Furthermore, Cygwin supports
displaying these terminal sequences properly (unlike MSYS).
This patch changes the mode auto-detection logic on Windows to be more
conservative about selecting the "ansi" mode. We now only select the
"ansi" mode if TERM is set and it contains the string "xterm" or if
we were unable to talk to win32 APIs to determine the settings. There is
a chance this may take away "ansi" from a terminal that actually
supports it. The recourse for this would be to patch the detection to
act appropriately and to override color.mode until that patch has
landed. However, the author believes this regression is tolerable, since
it means MSYS users won't have gibberish printed by default.
Since MSYS's common pager (less) supports display of ANSI sequences,
there is room to patch the color extensions so it can select the ANSI
color mode if a pager is activated.
Mozilla (being an active user of MSYS) would really appreciate this
being part of the stable branch. However, since I believe it is BC, I
haven't explicitly requested application to stable since I figure that
request will be denied.
Matt Mackall <mpm@selenic.com> [Tue, 03 Feb 2015 19:10:03 -0600] rev 24027
merge with stable
Eric Sumner <ericsumner@fb.com> [Wed, 14 Jan 2015 14:24:16 -0800] rev 24026
bundle2.unpackermixin: control for underlying file descriptor
This patch adds seek(), tell(), and close() implementations for unpackermixin
which forward to the file descriptor's implementation if possible. A future
patch will use this to make bundle2.unbundlepart seekable, which will in turn
make it usable as a file descriptor for bundlerepo.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:34:03 -0800] rev 24025
trydiff: join elements in 'header' list by '\n'
It seems natural that each element in the list corresponds to one line
of output. That is currently true, but only because each element in
the list has a trailing newline. Let's drop those newlines and instead
add them when we print the headers.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:27:04 -0800] rev 24024
trydiff: move check for quietness out of diffline()
By moving the condition out of diffline(), the call site becomes
clearer and diffline() no longer closes on any variables.
Note that this changes the value of the header variable from [''] to
[], but there is no difference in how these two are treated by the
following code. The new value seems more natural anyway.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:22:29 -0800] rev 24023
trydiff: remove dead branch in diffline()
Since diffline() is never called when 'revs' is empty, it doesn't need
to handle that case.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:19:57 -0800] rev 24022
trydiff: make 'revs' ignored if opts.git is set
Instead of setting revs=None to prevent the call to diffline() when
opts.git is set, explicitly do not call the function in the git case.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:58:51 -0800] rev 24021
trydiff: remove unused argument to diffline()
Now that diffline no longer knows about copies/renames, it only needs
one argument for the path.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:58:06 -0800] rev 24020
trydiff: move git-header code out of diffline function
This collects more of the code for writing git headers in a single
place and makes diffline() close on a few variables less.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 27 Jan 2015 09:22:59 -0500] rev 24019
_fm1readmarkers: generate list in C
This moves perfloadmarkers from
! result: 63866
! wall 0.239217 comb 0.250000 user 0.240000 sys 0.010000 (best of 42)
to
! result: 63866
! wall 0.218795 comb 0.210000 user 0.210000 sys 0.000000 (best of 46)
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 13:38:07 -0500] rev 24018
obsolete: use parsers.fm1readmarker if it exists for a ~38% perf win
This moves perfloadmarkers on my linux workstation (63494 markers from
mpm, crew, and myself) performance from
! wall 0.357657 comb 0.360000 user 0.350000 sys 0.010000 (best of 28)
to
! wall 0.222345 comb 0.220000 user 0.210000 sys 0.010000 (best of 41)
which is a pretty good improvement.
On my BSD machine, which is ancient and slow, before:
! wall 3.584964 comb 3.578125 user 3.539062 sys 0.039062 (best of 3)
after:
! wall 2.267974 comb 2.265625 user 2.195312 sys 0.070312 (best of 5)
I feel like we could do better by moving the whole generator function
into C, but I didn't want to tackle that right away.
Augie Fackler <augie@google.com> [Fri, 23 Jan 2015 15:11:25 -0500] rev 24017
parsers: add fm1readmarker
This lets us do most of the interesting work of parsing obsolete
markers in C, which should provide significant time savings.
Thanks to Martin von Zweigbergk for some cleanups on this code.
Augie Fackler <augie@google.com> [Tue, 03 Feb 2015 13:17:21 -0500] rev 24016
util: add getbefloat64
As far as I can tell, this is wrong. double's format isn't strictly
specified in the C standard, but the wikipedia article implies that
platforms implementing optional Annex F "IEC 60559 floating-point
arithmetic" will work correctly.
My local C experts believe doing *((double *) &t) is a strict aliasing
violation, and that using a union is also one. Doing memcpy appears to
be the least-undefined behavior possible.
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 14:09:57 -0500] rev 24015
util: add getbe{u,}int16 utility methods
Augie Fackler <augie@google.com> [Tue, 20 Jan 2015 09:38:22 -0500] rev 24014
obsolete: make optional offset parameter to fm*readmarkers required
It was always passed by the only callsite, so just make it required.
Augie Fackler <augie@google.com> [Mon, 02 Feb 2015 14:26:47 -0500] rev 24013
log: fix json-formatted output when file copies are listed (issue4523)
Matt Mackall <mpm@selenic.com> [Tue, 03 Feb 2015 17:54:01 -0600] rev 24012
merge with stable
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 17:24:12 -0800] rev 24011
copy: move _forwardcopies file logic to a function
Moves the _forwardcopies missingfiles logic to a separate function so that other
extensions which need to prefetch information about the files being
processed have a hook point.
This saves extensions from having to recompute this information themselves, and
thus saves several seconds off of various commands (like rebase).
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 17:23:18 -0800] rev 24010
copy: move mergecopies file logic to a function
Moves the mergecopies nonoverlap logic to a separate function so that other
extensions which may need to prefetch information about the files being
processed have a hook point.
This saves extensions from having to recompute this information themselves, and
thus saves several seconds off of various commands (like rebase).
Durham Goode <durham@fb.com> [Mon, 02 Feb 2015 16:19:35 -0800] rev 24009
histedit: allow configuring default behavior
Adds a configuration setting for allowing users to specify the default behavior
of 'hg histedit' without arguments. This saves users from having to manually
figure out the bottom commit or a complicated revset. My current revset of
choice is "only(.) & draft() - ::merge()"
The commits that histedit can work with is usually quite limited, so if this
feature ends up working well, we may want to consider making "only(.) & draft()
- ::merge()" the default behavior for everyone.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 03 Feb 2015 21:56:29 +0900] rev 24008
revset: get revision number of each node from target namespaces
Before this patch, revset predicate "named()" uses each nodes gotten
from target namespaces directly.
This causes problems below:
- combination of other predicates doesn't work correctly, because
they assume that revisions are listed up in number
- "hg log" doesn't show any revisions for "named()" result, because:
- "changeset_printer" stores formatted output for each revisions
into dict with revision number (= ctx.rev()) as a key of them
- "changeset_printer.flush(rev)" writes stored output for
the specified revision, but
- "commands.log" invokes it with the node, gotten from "named()"
- "hg debugrevspec" shows nodes (= may be binary) directly
Difference between revset predicate "tag()" and "named('tags')" in
tests is fixed in subsequent patch.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 01 Feb 2015 14:05:15 -0500] rev 24007
largefiles: update _subdirlfs() comment
http://www.selenic.com/pipermail/mercurial-devel/2015-February/065958.html
Matt Harbison <matt_harbison@yahoo.com> [Sat, 31 Jan 2015 00:13:29 -0500] rev 24006
largefiles: use the core file copy logic to validate the destination path
The destination is validated by pathutil.canonpath() for illegal components, and
that it is in the repository. The logic for creating the standin directory tree
was calling this before cmdutil.copy(), but without the destination file name
component. The cmdutil.copy() logic also calls pathutil.canonpath(), but with
the file name component. By always calling the core logic first, the error
message is always consistent. Specifically, the old behavior for these tests
was to say '.hg' contains an illegal component, and '..' is not under root.
A user wasn't likely to notice the discrepancy, but this eliminates a needless
difference when running the test suite with --config extensions.largefiles=.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 15:40:59 -0800] rev 24005
trydiff: inline indexmeta()
The function is trivial and is only called in one place.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 23 Jan 2015 14:09:49 -0800] rev 24004
parsers: rewrite index_ancestors() in terms of index_commonancestorsheads()
The first 80% of index_ancestors() is identical to
index_commonancestorsheads(), so just call that function instead.
Mike Edgar <adgar@google.com> [Thu, 22 Jan 2015 11:09:34 -0500] rev 24003
filelog: remove unused _file method
Mateusz Kwapich <mitrandir@fb.com> [Mon, 26 Jan 2015 15:18:07 -0800] rev 24002
histedit: store full node hash in rules
Previously histedit only stored the short version of the rule nodes in the
state. This meant that later we couldn't resolve a rule node to its full
form if the commit had been deleted from the repo.
Let's store the full form from the beginning.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:49:08 -0800] rev 24001
trydiff: order header-writing code in same order as output
Instead of inserting a line before the others header lines, move the
code that writes that line before the code that writes the other
lines.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:53:37 -0800] rev 24000
trydiff: inline sole addmodehdr() call
Now that there is only a single call to addmodehdr() left, and there
is other similar code (for new/deleted files) around that call site,
let's inline the function there. That also makes it clearer under what
circumstances the header is actually written (when modes differ).
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 14:46:03 -0800] rev 23999
trydiff: join filename with prefix only once
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Jan 2015 17:00:54 -0800] rev 23998
trydiff: collect header-writing in one place
This is the first step towards simplifying the big loop in
trydiff(). This will make both the header code and the non-header code
clearer, and it prepares for further simplification of the many nested
if-statements in the body of the loop.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 10:57:13 -0800] rev 23997
trydiff: make variable names more consistent
Use '1' and '2' as suffix for names just like in the parameters
'ctx[12]':
to,tn -> content1,content2
a,b -> f1, f2
omode,mode -> mode1,mode2
omode,nmode -> mode1,mode2
onode,nnode -> node1,node2
oflag,nflag -> flag1,flag2
oindex,nindex -> index1,index2
Martin von Zweigbergk <martinvonz@google.com> [Fri, 16 Jan 2015 17:01:58 -0800] rev 23996
trydiff: check only if added file is a copy target, not source
When creating a diff with copy/rename enabled, we consider added files
and check if they are either copy sources or targets. However, an
added file should never be a copy source. The test suite seems to
agree with this: all tests pass if we raise an exception when an added
file is a copy source. So, let's simplify the code by dropping the
conditions that are never true.
For those interested in the historical reasons:
Before commit d1f209bb9564 (patch: separate reverse copy data
(issue1959), 2010-02-11), 'copy' seems to have been a bidirectional
map. Then that commit split it up into two unidirectional maps and
duplicated the logic to look in both maps. It was still needed at that
point to look in both maps, as the copy detection was poor and could
sometimes be reported in reverse.
A little later came 91eb4512edd0 (copies: rewrite copy detection for
non-merge users, 2012-01-04). That commit fixed the copy detection to
be backwards when it should, and made the hacks in trydiff
unnecessary.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Jan 2015 21:12:35 -0800] rev 23995
trydiff: remove unused variable 'modifiedset'
We started updating 'modifiedset' in a9853fc172d2 (trydiff: simplify
checking for additions, 2014-12-23) but in the same commit, we removed
the last use of the variable. Clean it up.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 02 Feb 2015 23:07:04 +0900] rev 23994
revset: replace parsing alias definition by _parsealiasdefn to parse strictly
Before this patch, referring alias arguments is parsed by string base
operation "str.replace".
This causes problems below (see the previous patch introducing
"_parsealiasdefn" for detail)
- the shorter name argument breaks referring the longer name
- argument names in the quoted string are broken
This patch replaces parsing alias definition by "_parsealiasdefn" to
parse strictly.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 02 Feb 2015 23:07:04 +0900] rev 23993
revset: introduce _parsealiasdefn to parse alias definitions strictly
This patch introduces "_parsealiasdefn" to parse alias definitions
strictly. For example, it can avoid problems below, which current
implementation can't.
- the shorter name argument breaks referring the longer name one in
the definition, if the former is completely prefix of the latter
for example, the alias definition "foo($1, $10) = $1 or $10" is
parsed as "_aliasarg('$1') or _aliasarg('$1')0" and causes parse
error, because tail "0" of "_aliasarg('$1')0" is invalid.
- argument names in the quoted string are broken
for example, the definition "foo($1) = $1 or desc('$1')" is parsed
as "_aliasarg('$1') or desc('_aliasarg(\'$1\')')" and causes
unexpected description matching against not '$1' but '_aliasarg(\'$1\')'.
To decrease complication of patch, current implementation for alias
definitions is replaced by "_parsealiasdefn" in the subsequent
patch. This patch just introduces it.
This patch defines "_parsealiasdefn" not as a method of "revsetalias"
class but as a one of "revset" module, because of ease of testing by
doctest.
Yuya Nishihara <yuya@tcha.org> [Mon, 02 Feb 2015 22:28:52 +0900] rev 23992
hgweb: use revset.spanset where appropriate
It is remainder of 9ad6dae67845 where spanset was introduced.
Mathias De Maré <mathias.demare@gmail.com> [Sun, 01 Feb 2015 14:09:31 +0100] rev 23991
subrepo: add 'cat' support for git subrepos
V2: use 'self._ctx.node()' instead of 'rev' in makefileobj.
As Matt Harbison mentioned, using 'rev' does not make sense,
since we'd be passing a git revision to the top-level
Mercurial repository.
Matt Mackall <mpm@selenic.com> [Mon, 02 Feb 2015 12:50:48 -0600] rev 23990
merge with stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 20:21:02 -0600] rev 23989
Added signature for changeset fbdd5195528f
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 20:20:51 -0600] rev 23988
Added tag 3.3 for changeset fbdd5195528f
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 18:47:04 -0600] rev 23987
merge with i18n
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Feb 2015 08:24:08 +0900] rev 23986
i18n-ja: synchronized with 9a391d720cf9
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 29 Jan 2015 10:13:18 -0200] rev 23985
i18n-pt_BR: synchronized with 448bb32b8ee6
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:33:45 -0600] rev 23984
filectx: use _descendantrev in parents()
This lets us be lazy about linkrev adjustments when tracing history.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:26:35 -0600] rev 23983
filectx: if we have a _descendantrev, use it to adjust linkrev
This lets us use _adjustlinkrev lazily.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:25:12 -0600] rev 23982
copies: use linkrev for file tracing limit
This lets us lazily evaluate _adjustlinkrev.
Matt Mackall <mpm@selenic.com> [Sun, 01 Feb 2015 16:23:07 -0600] rev 23981
filectx: use linkrev to sort ancestors
We're going to make rev() lazily do _adjustlinkrevs, and we don't want
that to happen when we're quickly tracing through file ancestry
without caring about revs (as we do when finding copies).
This takes us back to pre-linkrev-correction behavior, but shouldn't
regress us relative to the last stable release.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 16:02:28 +0000] rev 23980
_adjustlinkrev: reuse ancestors set during rename detection (issue4514)
The new linkrev adjustement mechanism makes rename detection very slow, because
each file rewalks the ancestor dag. To mitigate the issue in Mercurial 3.3, we
introduce a simplistic way to share the ancestors computation for the linkrev
validation phase.
We can reuse the ancestors in that case because we do not care about
sub-branching in the ancestors graph.
The cached set will be use to check if the linkrev is valid in the search
context. This is the vast majority of the ancestors usage during copies search
since the uncached one will only be used when linkrev is invalid, which is
hopefully rare.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 14:39:03 +0000] rev 23979
filectx: move _adjustlinkrev to a method
We are going to introduce some wider caching mechanisms during linkrev
adjustment. As there is no specific reason to not be a method and some
reasons to be a method, let's make it a method.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 31 Jan 2015 01:00:50 +0900] rev 23978
revset: raise RepoLookupError to make present() predicate continue the query
Before this patch, "bookmark()", "named()" and "tag()" predicates
raise "Abort", when the specified pattern doesn't match against
existing ones.
This prevents "present()" predicate from continuing the query, because
it only catches "RepoLookupError".
This patch raises "RepoLookupError" instead of "Abort", to make
"present()" predicate continue the query, even if "bookmark()",
"named()" or "tag()" in the sub-query of it are aborted.
This patch doesn't contain raising "RepoLookupError" for "re:" pattern
in "tag()", because "tag()" treats it differently from others. Actions
of each predicates at failure of pattern matching can be summarized as
below:
predicate "literal:" "re:"
---------- ----------- ------------
bookmark abort abort
named abort abort
tag abort continue (*1)
branch abort continue (*2)
---------- ----------- ------------
"tag()" may have to abort in the (*1) case for similarity, but this
change may break backward compatibility of existing revset queries. It
seems to have to be changed on "default" branch (with "BC" ?).
On the other hand, (*2) seems to be reasonable, even though it breaks
similarity, because "branch()" in this case doesn't check exact
existence of branches, but does pick up revisions of which branch
matches against the pattern.
This patch also adds tests for "branch()" to clarify behavior around
"present()" of similar predicates, even though this patch doesn't
change "branch()".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 01 Feb 2015 09:36:47 +0900] rev 23977
templatekw: re-add showtags() to list tags keyword up in online help
Changeset d69a7fc68ad5 removed "showtags()" definition for "tags"
template keyword from "templatekw.py", because "namespaces" puts a
helper function for it into template keyword map automatically. This
works correctly from the point of view of templating functionality.
But on the other hand, it removed "tags" template keyword from "hg
help templates" unexpectedly, because online help text is built before
"namespaces" puts a helper function for "tags" into template keyword
map.
This patch is a kind of backing d69a7fc68ad5 out, but this implements
"showtags()" with newly introduced "shownames()" instead of originally
used "showlist()".
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Jan 2015 20:44:11 -0500] rev 23976
largefiles: don't interfere with logging normal files
The previous code was adding standin files to the matcher's file list when
neither the standin file nor the original existed in the context. Somehow, this
was confusing the logging code into behaving differently from when the extension
wasn't loaded.
It seems that this was an attempt to support naming a directory that only
contains largefiles, as a test fails if the else clause is dropped entirely.
Therefore, only append the "standin" if it is a directory. This was found by
running the test suite with --config extensions.largefiles=.
The first added test used to log an additional cset that wasn't logged normally.
The only relation it had to file 'a' is that 'a' was the source of a move, but
it isn't clear why having '.hglf/a' in the list causes this change:
@@ -47,6 +47,11 @@
Make sure largefiles doesn't interfere with logging a regular file
$ hg log a --config extensions.largefiles=
+ changeset: 3:2ca5ba701980
+ user: test
+ date: Thu Jan 01 00:00:04 1970 +0000
+ summary: d
+
changeset: 0:9161b9aeaf16
user: test
date: Thu Jan 01 00:00:01 1970 +0000
The second added test used to complain about a file not being in the parent
revision:
@@ -1638,10 +1643,8 @@
Ensure that largefiles doesn't intefere with following a normal file
$ hg --config extensions.largefiles= log -f d -T '{desc}' -G
- @ c
- |
- o a
-
+ abort: cannot follow file not in parent revision: ".hglf/d"
+ [255]
$ hg log -f d/a -T '{desc}' -G
@ c
|
Note that there is still something fishy with the largefiles code, because when
using a glob pattern like this:
$ hg log 'glob:sub/*'
the pattern list would contain '.hglf/glob:sub/*'. None of the tests show this
(this test lives in test-largefiles.t at 1349), it was just something that I
noticed when the code was loaded up with print statements.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 21:11:02 +0000] rev 23975
discovery: properly exclude locally known but filtered heads
The conditional was a bit too narrow and produced buggy result when a node was
present in both common and heads (because it pleased the discovery) and it was
locally known but filtered.
This resulted in buggy getbundle request and server side crash.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 21:40:30 +0000] rev 23974
test: make test-extdiff resilient to /usr/bin/echo
My test machine has 'echo' in '/usb/bin/echo', #dontaskmewhy.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 30 Jan 2015 18:49:33 +0000] rev 23973
obsstore: make the invalid markers check wrap-able
Some evolve user ignored the invalid markers for about two years and still have
some of them in some repository. This lead to plain abort whenever mercurial try
to open such repo. We need reinstall some way to clean this up in the evolve
extension. For this purpose, we need the checker code wrap-able independently.
This is scheduled for stable as this issue is blocking some evolve user.
Mads Kiilerich <madski@unity3d.com> [Fri, 30 Jan 2015 18:51:20 +0100] rev 23972
convert: replace revision references in messages if they are >= short hashes
Convert will try to find references to revisions in commit messages and replace
them with references to the converted revision. It will take any string that
looks like a hash (and thus also decimal numbers) and look it up in the source
repo. If it finds anything, it will use that in the commit message instead.
It would do that for all hex digit sequences of 6 to 40 characters. That was
usually no problem for small repos where it was unlikely that there would be a
matching 6 'digit' hash prefix. It was also no problem on repos with less than
100000 changesets where numbers with 6 or more digits not would match any
revision number. With more than 100000 revisions random numbers in commit
messages would be replaced with a "random" hash. For example, 'handle 100000
requests' would be changed to to 'handle 9117c6 requests'. Convert could thus
not really be used on real repositories with more than 100000 changesets.
The default hash length shown by Mercurial is 12 'digits'. It is unexpected and
unwanted that convert by default tries to replace revision references that use
less than that amount of 'digits'.
To fix this, don't match strings that are less than the default hash size of 12
characters.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 30 Jan 2015 04:59:05 +0900] rev 23971
merge: mark .hgsubstate as possibly dirty before submerge for consistency
Before this patch, failure of updating subrepos may cause inconsistent
".hgsubstate". For example:
1. dirstate entry for ".hgsubstate" of the parent repo is filled
with valid size/date (via "hg state" or so)
2. "hg update" is invoked at the parent repo
3. ".hgsubstate" of the parent repo is updated on the filesystem as
a part of "g"(et) action in "merge.applyupdates"
4. it is assumed that size/date of ".hgsubstate" on the filesystem
aren't changed from ones at (1)
this is not so difficult condition, because just changing hash
ids (every ids are same in length) in ".hgsubstate" doesn't
change the file size of it
5. "subrepo.submerge()" is invoked to update subrepos
6. failure of updating in one of subrepos raises exception
(e.g. "untracked file differs")
7. "hg update" is aborted without updating dirstate of the parent repo
dirstate entry for ".hgsubstate" still holds size/date at (1)
Then, ".hgsubstate" of the parent repo is treated as "CLEAN"
unexpectedly, because updating ".hgsubstate" at (3) doesn't change
size/date of it on the filesystem: see assumption at (4).
This inconsistent ".hgsubstate" status causes unexpected behavior, for
example:
- "hg revert" forgets to revert ".hgsubstate"
- "hg update" misunderstands that (not yet updated) subrepos diverge
(then, it shows the prompt to confirm user's decision)
To avoid inconsistent ".hgsubstate" status above, this patch marks
".hgsubstate" as possibly dirty before "submerge" invocation.
"normallookup"-ed (= dirty) dirstate should be written out, even if
processing is aborted by failure.
This patch marks ".hgsubstate" as possibly dirty before "submerge",
also when it is removed or merged while merging, for safety. This
should prevent Mercurial from misunderstanding inconsistent
".hgsubstate" as clean.
To satisfy conditions at (1) and (4) above, this patch uses "hg status
--config debug.dirstate.delaywrite=2" (to fill valid size/date into
dirstate) and "touch" (to fix date of the file).
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 27 Jan 2015 12:33:56 +0000] rev 23970
rebase: ensure rebase revision remains visible (issue4504)
Before this changeset rebase was getting very confused if any revision in the
rebase set became hidden. This was fairly easy to achieve if a rebased revision
was made visible by the working copy location. The rebase process would update
somewhere else and the revision would become hidden.
To work around this issue, we ensure rebased revisions remain visible for the
whole process.
This is a simple change suitable for stable. More subtle usage of unfiltered
repository in rebase may solve this issue more cleanly.
Mads Kiilerich <madski@unity3d.com> [Wed, 28 Jan 2015 02:28:39 +0100] rev 23969
extdiff: reintroduce backward compatibility with manual quoting of parameters
72a89cf86fcd broke things ... and the following cleanups didn't fix all issues.
It didn't work with the diffargs shipped in mergetools.rc with explicit
quoting. Parameters would end up with being quoted twice - especially if they
really needed quoting.
To work around that, look for explicit quotes around the variables that will be
substituted with proper quoting. Also accept an additional prefix so we can
handle both
--foo='$parent'
and
'--foo=$parent'
It will however still fail if the user intentionally place the variable inside
a quoted string, as in
'parent $parent is on the left'
There is currently no good way to handle that, short of knowing exactly which
quoting mechanism will be used.