Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Jul 2014 10:52:58 -0700] rev 21866
localrepo: document localrepo.hook()
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21865
filemerge: use 'util.ellipsis' to trim custom conflict markers correctly
Before this patch, filemerge slices byte sequence directly to trim
conflict markers, but this may cause:
- splitting at intermediate multi-byte sequence
- incorrect calculation of column width (length of byte sequence is
different from columns in display in many cases)
This patch uses 'util.ellipsis' to trim custom conflict markers
correctly, even if multi-byte characters are used in them.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21864
filemerge: use only the first line of the generated conflict marker for safety
Before this patch, with careless configuration (missing '|firstline'
filtering for '{desc}' keyword, for example), '[ui]
mergemarkertemplate' can make conflict markers multiple lines.
For ordinary users, advantage of allowing '[ui] mergemarkertemplate'
to generate multiple lines for customizing seems to be less than
advantage of disallowing it for safety.
This patch uses only the first line of the conflict marker generated
from '[ui] mergemarkertemplate' configuration for safety.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21863
progress: use 'encoding.colwidth' to get column width of items correctly
Before this patch, 'progress' extension applies 'len' on byte sequence
to get column width of it, but it causes incorrect result, when length
of byte sequence and columns in display are different from each other
in multi-byte characters.
This patch uses 'encoding.colwidth' to get column width of items in
output line correctly, even if it contains multi-byte characters.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21862
progress: use 'encoding.trim' to trim items in output line correctly
Before this patch, 'progress' extension trims items in output line by
directly slicing byte sequence, but it may split at intermediate
multi-byte sequence.
This patch uses 'encoding.trim' to trim items in output line
correctly, even if it contains multi-byte characters.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21861
encoding: add 'leftside' argument into 'trim' to switch trimming side
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21860
progress: use 'encoding.colwidth' to get column width of output line correctly
Before this patch, 'progress' extension applies 'len' on byte sequence
to get column width of it, but it causes incorrect result, when length
of byte sequence and columns in display are different from each other
in multi-byte characters.
This patch uses 'encoding.colwidth' to get column width of output line
correctly, even if it contains multi-byte characters.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21859
progress: use 'encoding.trim' to trim output line correctly
Before this patch, 'progress' extension trims output line by directly
slicing byte sequence, but it may split at intermediate multi-byte
sequence.
This patch uses 'encoding.trim' to trim output line correctly, even if
it contains multi-byte characters.
"rm -f loop.pyc" before changing "loop.py" in "test-progress.t"
ensures that re-compilation of "loop.py", even if "loop.py" and
"loop.pyc" have same timestamp in seconds.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21858
histedit: use 'util.ellipsis' to trim description of each changesets
Before this patch, trimming description of each changesets in histedit
may split at intermediate multi-byte sequence.
This patch uses 'util.ellipsis' to trim description of each changesets
instead of directly slicing byte sequence.
Even though 'util.ellipsis' adds '...' as ellipsis when specified
string is trimmed (= this changes result of trimming), this patch uses
it, because:
- it can be used without any additional 'import', and
- ellipsis seems to be better than just trimming, for usability
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21857
util: replace 'ellipsis' implementation by 'encoding.trim'
Before this patch, 'util.ellipsis' tried to avoid splitting at
intermediate multi-byte sequence, but its implementation was incorrect.
Internal function '_ellipsis' trims specified unicode sequence not at
most maxlength 'columns in display', but at most maxlength number of
'unicode characters'.
def _ellipsis(text, maxlength):
if len(text) <= maxlength:
return text, False
else:
return "%s..." % (text[:maxlength - 3]), True
In many encodings, number of unicode characters can be different from
columns in display.
This patch replaces 'ellipsis' implementation by 'encoding.trim',
which can trim string at most maxlength columns in display correctly,
even though specified string contains multi-byte characters.
'_ellipsis' is removed in this patch, because it is referred only from
'ellipsis'.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 06 Jul 2014 02:56:41 +0900] rev 21856
encoding: add 'trim' to trim multi-byte characters at most specified columns
Newly added 'trim' is used to trim multi-byte characters at most
specified columns correctly: directly slicing byte sequence should be
replaced with 'encoding.trim', because the former may split at
intermediate multi-byte sequence.
Slicing unicode sequence ('uslice') and concatenation with ellipsis
('concat') are defined as function, to make enhancement in subsequent
patch easier.
Jim Hague <jim.hague@acm.org> [Thu, 03 Jul 2014 10:48:37 +0100] rev 21855
bugzilla: stop trying to cache setup across hook invocation
In the context of standalone Hg receiving a set of incoming changes, it makes
sense for the Bugzilla module to cache basic setup to avoid reconnecting
to Bugzilla for each change. After processing the changes, Hg will exit
and so the connection is short-lived.
But this doesn't work too well when used from a long-lived environment
such as hgweb or Kallithea where, for example, the connection can time out.
So take the simple approach, abandon the cache and do the basic setup on
each call. This fixes current problems with Kallithea.
Matt Mackall <mpm@selenic.com> [Fri, 11 Jul 2014 18:04:51 -0500] rev 21854
strip: drop -b/--backup option (BC)
This option had very limited utility and counterintuitive behavior and
collided unfortunately with the much later -B option.
Normally we would no-op such a feature so as to avoid annoying existing
scripts. However, we have to weigh that against the silent misbehavior
that results when users mistakenly intended to use -B: because -b
takes no arg, the bookmark gets interpreted as a normal revision, and
gets stripped without removing the associated bookmark, while also not
backing up the revision in question. A no-op behavior or warning would only
remove the latter half of the misadventure.
The only users I can find of this feature were using it in error and
have since stopped. The few (if any) remaining users of this feature
would be better served by --no-backup.
Ben Kehoe <benk@berkeley.edu> [Thu, 07 Nov 2013 17:24:14 -0800] rev 21853
purge: add options for deleting only files or only directories