graphlog: multiple --keyword must be or'ed

graphlog: multiple --branch must be or'ed

graphlog: multiple --user must be or'ed

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.

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

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.

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.

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.

status: fix format field thinko

largefiles: don't break filesets

help: sort hgrc related "Sections" chapters alphabetically

doc: minor fixes to [graph] section documentation

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.

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.

formatter: convert status command

ui: add formatter method

formatter: add basic formatters

encoding: introduce utf8-b helpers

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.

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

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

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

merge with stable

filemerge: remove some redundancy in decorators/docstrings

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'.

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.

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).

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.