Ryan McElroy <rmcelroy@fb.com> [Tue, 09 Feb 2016 15:25:09 -0800] rev 28070
merge: add some useful documentation
Yuya Nishihara <yuya@tcha.org> [Sun, 27 Dec 2015 19:58:11 +0900] rev 28069
encoding: backport paranoid escaping from templatefilters.jsonescape()
This was introduced by 55c763926a28. It is required to embed JSON data in
HTML page. Convince yourself here:
http://escape.alf.nu/1
Yuya Nishihara <yuya@tcha.org> [Sun, 27 Dec 2015 19:28:34 +0900] rev 28068
encoding: add option to escape non-ascii characters in JSON
This is necessary for hgweb to embed JSON data in HTML. JSON data must be
able to be embedded in non-UTF-8 HTML page so long as the page encoding is
compatible with ASCII.
According to RFC 7159, non-BMP character is represented as UTF-16 surrogate
pair. This function first splits an input string into an array of UTF-16
code points.
https://tools.ietf.org/html/rfc7159.html#section-7
Yuya Nishihara <yuya@tcha.org> [Sat, 30 Jan 2016 19:48:35 +0900] rev 28067
encoding: initialize jsonmap when module is loaded
This makes jsonescape() a thread-safe function, which is necessary for hgweb.
The initialization stuff isn't that slow:
$ python -m timeit -n1000 -s 'from mercurial import encoding as x' 'reload(x)'
original: 1000 loops, best of 3: 158 usec per loop
this patch: 1000 loops, best of 3: 214 usec per loop
compared to loading the commands module:
$ python -m timeit -n1000 -s 'from mercurial import commands as x' 'reload(x)'
1000 loops, best of 3: 1.11 msec per loop
Yuya Nishihara <yuya@tcha.org> [Sat, 30 Jan 2016 19:41:34 +0900] rev 28066
encoding: change jsonmap to a list indexed by code point
This is slightly faster and convenient to implement a paranoid escaping.
$ python -m timeit \
-s 'from mercurial import encoding; data = str(bytearray(xrange(128)))' \
'encoding.jsonescape(data)'
original: 100000 loops, best of 3: 15.1 usec per loop
this patch: 100000 loops, best of 3: 13.7 usec per loop
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Feb 2016 15:24:11 +0000] rev 28065
update: change default destination to tipmost descendant (issue4673) (BC)
Bare 'hg update' now brings you to the tipmost descendant (on the same branch).
Leaving the user on the same topological branch. The previous behavior, updating
to the tipmost changeset on the same branch could lead to jump from a
topological branch to another. This was confusing and impractical. As the only
conceivable reason for the old behavior have been address by the recently
introduce message about other heads, we can "safely" change this behavior
All test changes have been reviewed and seen a valid consequences.