Mon, 14 Jul 2014 12:44:45 -0500 templates: escape NUL bytes in jsonescape (issue4303) stable
Matt Mackall <mpm@selenic.com> [Mon, 14 Jul 2014 12:44:45 -0500] rev 21867
templates: escape NUL bytes in jsonescape (issue4303) It's currently possible for various fields to contain NUL bytes, which are disallowed in JSON.
Sat, 12 Jul 2014 10:52:58 -0700 localrepo: document localrepo.hook()
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Jul 2014 10:52:58 -0700] rev 21866
localrepo: document localrepo.hook()
Sun, 06 Jul 2014 02:56:41 +0900 filemerge: use 'util.ellipsis' to trim custom conflict markers correctly
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.
Sun, 06 Jul 2014 02:56:41 +0900 filemerge: use only the first line of the generated conflict marker for safety
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.
Sun, 06 Jul 2014 02:56:41 +0900 progress: use 'encoding.colwidth' to get column width of items correctly
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.
Sun, 06 Jul 2014 02:56:41 +0900 progress: use 'encoding.trim' to trim items in output line correctly
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.
Sun, 06 Jul 2014 02:56:41 +0900 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 21861
encoding: add 'leftside' argument into 'trim' to switch trimming side
Sun, 06 Jul 2014 02:56:41 +0900 progress: use 'encoding.colwidth' to get column width of output line correctly
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.
Sun, 06 Jul 2014 02:56:41 +0900 progress: use 'encoding.trim' to trim output line correctly
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.
Sun, 06 Jul 2014 02:56:41 +0900 histedit: use 'util.ellipsis' to trim description of each changesets
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
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip