Matt Mackall <mpm@selenic.com> [Fri, 19 Sep 2014 12:51:15 -0500] rev 22464
color: change the debug output format
Before, the format was
label(labeled text) # single label
[label1 label2](labeled text) # multiple
Now, it's
[labels|labeled text]
..which should make things a bit more clear.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Sun, 24 Aug 2014 17:40:27 -0400] rev 22463
color: enable debug option to show labels
This is a debug option for showing labels. This can be helpful for
knowing which labels are available for colouring or to see the output
when defining your own templates. A couple of tests are included.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Sun, 24 Aug 2014 17:35:36 -0400] rev 22462
color: document that labels are used for colorizing text
It is a deeply hidden secret that it's possible to colorise so many
things with so many different labels. This is an attempt to document
this. The text is a bit long, but it seems as short as can be while
documenting everything. Perhaps it should be hidden under a --verbose
option.
Mads Kiilerich <madski@unity3d.com> [Wed, 27 Aug 2014 16:39:44 +0200] rev 22461
contrib: add OS X p4merge to mergetools.hgrc
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 20 Aug 2014 15:15:50 -0400] rev 22460
patch: enable diff.tab markup for the color extension
The following patch splits up changed lines along tabs (using
re.findall), and gives them a "diff.tab" label. This can be used by
the color extension for colorising tabs, like it does right now with
trailing whitespace.
I also provide corresponding tests.
Siddharth Agarwal <sid0@fb.com> [Wed, 17 Sep 2014 13:08:03 -0700] rev 22459
dirstate: copyedit exception for no beginparentchange call
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 07 Sep 2014 11:33:22 -0700] rev 22458
revsetbenchmarks: add an additional roots() benchmark
The existing roots(x - y) revset only considered the most recent 100
revisions. This was a good start. But expanding it to the full history
of the repository can dramatically increase execution time and thus
constitutes a useful benchmark.
Matt Mackall <mpm@selenic.com> [Tue, 16 Sep 2014 14:49:56 -0500] rev 22457
merge with stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 12 Sep 2014 02:29:19 +0900] rev 22456
mq: examine "pushable" of already applied patch correctly
Before this patch, "hg qselect" with --pop/--reapply may pop patches
unexpectedly, even when all of patches applied before "qselect" are
still pushable.
Strictly speaking about the condition of this issue:
- before "qselect"
- there are N applied patches
- the index of the guarded patch X in the series is less than N
- after "qselect"
- X is still guarded, and
- all of applied patched are still pushable
In the case above, "hg qselect" should keep current status, but it
actually tries to pop patches because of X.
The index in "the series" should be used to examine "pushable" of a
patch by "mq.pushablek()", but the index in "applied patches" is used,
and this may cause unexpected examination of guarded patch.
To examine "pushable" of already applied patch correctly, this patch
uses "mq.applied[i].name": "pushable" is the function introduced by
the previous patch, and it returns "mq.pushable(mq.applied[i].name)[0]".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 12 Sep 2014 02:29:19 +0900] rev 22455
mq: pop correct patches when changing pushable-ness of already applied ones
Before this patch, "hg qselect" with --pop/--reapply may pop incorrect
patches, because the index in "applied patches" is used to pop patches
by "mq.pop()", even though the index in "the series" should be used.
For example, when the already applied patch becomes guarded and it
follows the already guarded (= not yet applied) one, "hg qselect" is
aborted, because it tries to pop to guarded one.
This patch uses "mq.applied[i - 1].name" to pop to the patch, of which
the index in the "applied ones" is "i - 1".