FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 15 Jul 2014 00:59:09 +0900] rev 21869
cmdutil: separate building commit text from 'commitforceeditor'
This separation makes it easier to extend/hook building commit text
from the specified context.
This patch uses 'committext' instead of 'edittext' for names of newly
added variable and function, because the former is more purpose
specific than the latter, even though 'edittext' in 'buildcommittext'
is left as it is to reduce amount of diff.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 14 Jul 2014 23:33:59 +0900] rev 21868
convert: detect removal of ".gitmodules" at git source revisions correctly
Before this patch, all operations applied on ".gitmodules" at git
source revisions are treated as modification, even if they are
actually removal of it.
If removal of ".gitmodules" is treated as modification unexpectedly,
"hg convert" is aborted by the exception raised in
"retrievegitmodules()" for ".gitmodules" at the git source revision
removing it, because that revision doesn't have any information of
".gitmodules".
This patch detects removal of ".gitmodules" at git source revisions
correctly.
If ".gitmodules" is removed at the git source revision, this patch
records "hex(nullid)" as the contents hash value for ".hgsub" and
".hgsubstate" at the destination revision.
This patch makes "getfile()" raise IOError also for ".hgstatus" and
".hgsubstate" if the contents hash value is "hex(nullid)", and this
tells removal of ".hgstatus" and ".hgsubstate" at the destination
revision to "localrepository.commitctx()" correctly.
For files other than ".hgstatus" and ".hgsubstate", checking the
contents hash value in "getfile()" may be redundant, because
"catfile()" for them also does so.
But this patch chooses writing it only once at the beginning of
"getfile()", to avoid writing same code twice both for ".hgsub" and
".hgsubstate" separately.
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.
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.