hg-stable: Changelog

revset: maintain ordering when subtracting from a baseset (issue4289)

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.

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.

templates: escape NUL bytes in jsonescape (issue4303) It's currently possible for various fields to contain NUL bytes, which are disallowed in JSON.

localrepo: document localrepo.hook()

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.

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.

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.

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.