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.

--HG--
branch : stable
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.
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'.
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
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.
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.
encoding: add 'leftside' argument into 'trim' to switch trimming side
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.
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.
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.
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.
localrepo: document localrepo.hook()
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.
revset: maintain ordering when subtracting from a baseset (issue4289)

--HG--
extra : amend_source : f73d177de26ba0c4f10012f33345bb6c171ec288
parsers: remove unused getintat function

Warning detected by clang.
log: allow revset for --follow to be lazily evaluated

It is unclear to me why evaluation was forced.

For a repository with over 700,000 commits, 'hg log -f' drops from 1.2 seconds
to 0.2 seconds.
templates: escape NUL bytes in jsonescape (issue4303)

It's currently possible for various fields to contain NUL bytes, which
are disallowed in JSON.

--HG--
branch : stable
extra : amend_source : 8aa863340e4722c7b5651f4d2d30fa01de6038c5
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.

--HG--
branch : stable
merge with stable