Patrick Mezard <patrick@mezard.eu> [Wed, 22 Feb 2012 12:30:15 +0100] rev 16150
graphlog: multiple --keyword must be or'ed
Patrick Mezard <patrick@mezard.eu> [Wed, 22 Feb 2012 12:30:15 +0100] rev 16149
graphlog: multiple --branch must be or'ed
Patrick Mezard <patrick@mezard.eu> [Wed, 22 Feb 2012 12:30:15 +0100] rev 16148
graphlog: multiple --user must be or'ed
Patrick Mezard <patrick@mezard.eu> [Wed, 22 Feb 2012 12:30:15 +0100] rev 16147
graphlog: explicitely join multivalue parameters
This will let use override the "join" value (and/or) depending on the option
considered. The option revset arity is now deduced from the revset and the
option value type, to simplify opt2revset definition.
Patrick Mezard <patrick@mezard.eu> [Wed, 22 Feb 2012 12:30:14 +0100] rev 16146
test-glog.t: use printrevset extension to trace rewritten revsets
Using "hg log -G --print-revset" prints the revset generated by graphlog and
exits. This helps debugging and writing shorter tests.
It has been suggested to handle these tests with doctests. I think the
extension approach is better because:
- It tests the actual parameter set passed to graphlog.revset(), not what we
expect it to be. 'branch' and 'only-branch' are currently distinct options
but nothing prevents fancyopts to grow a notion of option aliasing one day,
where both options would be merged before reaching the command.
- It can be used as debug output interleaved with real log calls.
v2:
- Use a test extension instead of a global deprecated new option
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 23 Feb 2012 00:07:54 +0900] rev 16145
context: use 'changectx.dirs()' in 'walk()' for directory patterns
this patch uses 'changectx.dirs()' instead of nested loop, to examine
whether specified pattern is related to the context as a directory or not.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 23 Feb 2012 00:07:54 +0900] rev 16144
localrepository: use 'changectx.dirs()' in 'status()' for directory patterns
when pattern which does not match against any files in working context
is specified, current implementation of 'localrepository.status()'
decides whether warning message about it should be shown or not by
'f not in context'
this works correctly for 'file pattern', but not for 'directory
pattern', because 'f not in context' always returns True for
directories, even if they are related to the context.
this patch uses 'changectx.dirs()' to examine whether specified
pattern is related to the context as a directory or not.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 23 Feb 2012 00:07:54 +0900] rev 16143
context: add 'dirs()' to changectx/workingctx for directory patterns
this patch adds 'dirs()' to changectx/workingctx, which returns map of
all directories deduced from manifest, to examine whether specified
pattern is related to the context as directory or not quickly.
'workingctx.dirs()' uses 'dirstate.dirs()' rather than building
another copy of it.
Matt Mackall <mpm@selenic.com> [Wed, 22 Feb 2012 15:22:12 -0600] rev 16142
status: fix format field thinko
Dan Villiom Podlaski Christiansen <danchr@gmail.com> [Mon, 20 Feb 2012 17:59:48 +0100] rev 16141
largefiles: don't break filesets
Michal Sznajder <michalsznajder@gmail.com> [Sat, 18 Feb 2012 14:27:57 +0100] rev 16140
help: sort hgrc related "Sections" chapters alphabetically
Patrick Mezard <patrick@mezard.eu> [Sat, 18 Feb 2012 12:30:24 +0100] rev 16139
doc: minor fixes to [graph] section documentation
Patrick Mezard <patrick@mezard.eu> [Sun, 22 Jan 2012 19:35:26 +0700] rev 16138
hgweb: refactor graph customization javascript
- Avoid flipping lineWidth state around the edge() call, pass it to the
function instead.
- Pass the line width and color appended to the other parameters instead of in
a dictionary. The javascript code is simpler, no need to check for all
containers existence, and the JSON output is smaller.
- Reindent setColor() comments and fix code spacing.
Patrick Mezard <patrick@mezard.eu> [Fri, 17 Feb 2012 16:49:43 +0100] rev 16137
templates: move Graph.edge() implementation in mercurial.js
All implementation in graph.tmpl are the same. It can still be overriden if
necessary. There is no clear reason to keep it separated from mercurial.js.
Matt Mackall <mpm@selenic.com> [Mon, 20 Feb 2012 16:42:51 -0600] rev 16136
formatter: convert status command
Matt Mackall <mpm@selenic.com> [Mon, 20 Feb 2012 16:42:48 -0600] rev 16135
ui: add formatter method
Matt Mackall <mpm@selenic.com> [Mon, 20 Feb 2012 16:42:47 -0600] rev 16134
formatter: add basic formatters
Matt Mackall <mpm@selenic.com> [Mon, 20 Feb 2012 16:42:45 -0600] rev 16133
encoding: introduce utf8-b helpers
Matt Mackall <mpm@selenic.com> [Fri, 17 Feb 2012 13:53:41 -0600] rev 16132
graphmod: add config cache
Before, we'd lookup the branch for every edge segment in the entire
graph: extremely expensive. This happened even when no per-branch
settings existed.
Now we define a revision -> config cache function that's LRU-cached
and is a no-op when no configuration exists. Still not terribly fast,
but hopefully only one real branch lookup per revision. This might
degenerate for wide graphs as the LRU is hard-coded to 20 elements.
Matt Mackall <mpm@selenic.com> [Fri, 17 Feb 2012 13:53:19 -0600] rev 16131
graphmod: rewrite graph config validation
Our goal is not to strictly disallow _invalid_ input, simply disallow _hostile_ input.
Avoid using re
Avoid creating empty dicts when no branch parameters are recognized
Constantine Linnick <theaspect@gmail.com> [Sun, 22 Jan 2012 19:47:03 +0700] rev 16130
graph: in hgrc specify line color for main branch
You can specify color to visually distinguish main branch (trunk)
on hgweb's graph page. If color specified, all branch heads will share
same color. Settings format is branch_name.color = value, where color
is six hexadecimal digits e.g.:
[graph]
default.color = FF0000
Constantine Linnick <theaspect@gmail.com> [Sun, 22 Jan 2012 19:35:26 +0700] rev 16129
graph: in hgrc specify line width for main branch
You can specify width to visually distinguish main branch (trunk)
on hgweb's graph page. Settings format is branch_name.width = value,
where width in px e.g.:
[graph]
default.width = 3
Matt Mackall <mpm@selenic.com> [Thu, 16 Feb 2012 16:40:29 -0600] rev 16128
merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 16 Feb 2012 15:58:51 -0600] rev 16127
filemerge: remove some redundancy in decorators/docstrings
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 12 Feb 2012 21:38:12 +0900] rev 16126
filemerge: create detail of internal merge tools from documentation string
this patch introduces 'internaltoolsmarker' which creates detail of
each internal merge tools from documentation string for 'hg help merge-tools'.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 12 Feb 2012 21:38:12 +0900] rev 16125
filemerge: refactoring of 'filemerge()'
current 'filemerge.filemerge()' implementation is verfy complicated.
- it is not easy to add new internal merge tools
(only by patching on 'filemerge()', or replacing it completely)
- cleanup of temporary files is unsatisfactory
('internal:dump' does not, in fact)
this is patch for refactoring of 'filemerge()' to isolate each
internal merge tool implementations from 'filemerge()', and clean up
common part in it.
Patrick Mezard <patrick@mezard.eu> [Mon, 13 Feb 2012 17:22:35 +0100] rev 16124
patch: fuzz more aggressively to match patch(1) behaviour
The previous code was assuming a default context of 3 lines. When fuzzing, it
would take this value in account to reduce the amount of removed line from
hunks top or bottom. For instance, if a hunk has only 2 lines of bottom
context, fuzzing with fuzz=1 would do nothing and with fuzz=2 it would remove
one of those lines. A hunk with one line of bottom context could not be fuzzed
at all. patch(1) has apparently no such restrictions and takes the fuzz level
at face value.
- test-import.t: fuzz/offset changes at the beginning of file are explained by
the new fuzzing behaviour and match patch(1) ones. Patching locations are
different but those of my patch(1) do not make a lot of sense right now
(patched output are the same)
- test-import-bypass.t: more agressive fuzzing makes a patching supposed to
fail because of context, succeed. Change the diff to avoid this.
- test-mq-merge.t: more agressive fuzzing would allow the merged patch to apply
with fuzz, but fortunately we disallow this behaviour. The new output is
kept.
I have not enough experience with patch(1) fuzzing to know whether aligning our
implementation on it is a good or bad idea. Until now, it has been the
implementation reference. For instance, "qpush" tolerates fuzz (test-mq-merge.t
runs the special case of pushing merge revisions where fuzzing is forbidden).
Patrick Mezard <patrick@mezard.eu> [Mon, 13 Feb 2012 16:47:31 +0100] rev 16123
patch: fix fuzzing of hunks without previous lines (
issue3264)
When applying hunks such as:
@@ -2,1 +2,2 @@
context
+change
fuzzing would empty the "old" block and make patchfile.apply() traceback.
Instead, we apply the new block at specified location without testing.
The "bottom hunk" test was removed as patch(1) has no problem applying hunk
with no context in the middle of a file.