[PATCH 0 of 3] Highlighting for log & graphlog

Jason Harris jason at jasonfharris.com
Wed May 4 23:34:05 CDT 2011


On May 4, 2011, at 11:10 PM, Matt Mackall wrote:

> On Wed, 2011-05-04 at 16:34 +0200, Peter Arrenbrecht wrote:
>> On Tue, May 3, 2011 at 10:26 PM, Matt Mackall <mpm at selenic.com> wrote:
>>> On Tue, 2011-05-03 at 22:00 +0200, Benoit Boissinot wrote:
>>>> On Tue, May 3, 2011 at 9:52 PM, Matt Mackall <mpm at selenic.com> wrote:
>>>>> On Tue, 2011-05-03 at 21:45 +0200, Benoit Boissinot wrote:
>>>>>> 
>>>>>> It is nice for example with "outgoing()", I can easily see how the
>>>>>> outgoing csets fit into the whole graph.
>> 
>> I'm the one who suggested the feature. It was triggered by Benoit's
>> suggestion that we have a "sample(undecidedset)" revset to visualize
>> how set discovery takes samples. But there's other uses. Basically, it
>> boils down to being able to see things in context:
>> 
>> * Where was this file touched, on what lines development?
>> * Same for authors.
>> * Highlight all ancestors/descendants of this node.
>> * Highlight this named branch.
>> 
>> In fact, I think we should maybe revisit the decision to try and align
>> log and glog. log is very much about speed and thus always walks the
>> changelog in revnum order. For glog, however, I think we should value
>> versatility over raw speed. It's a DAG visualizer. Once we see it as
>> such, we can do things like:
>> 
>> * Walk from all heads in breadth-first manner to get an overview of
>> what the heads are (maybe not exactly breadth-first, but a couple of
>> nodes at a time).
>> * Use the linearizing toposort of shrink-revlog and combine it with
>> the elision of linear runs (an old patch of mine) to get a concise
>> overview of branching/merging in a tree.
>> 
>> glog is very much about DAGs. I already took a first step in the
>> direction of making DAGs first class with dagutil.py (introduced by
>> set discovery). Benoit is working on moving the shrink-revlog toposort
>> there. Maybe we could also move Patrick's "redagging" (rebuilding a
>> DAG from a disconnected revset) there. So the more general DAG algos
>> would be clearly separate from visualizing them.
> 
> Teaching revlog's sort() about toposort might be useful.
> 
>> Then we could base glog on the DAGs exposed by dagutil. And we could
>> also easily add support for other visualizers like dot (which should
>> be configurable so it immediately launches a renderer and viewer) and
>> hgweb.
>> 
>> This way, glog and other visualizers could make the power of revsets
>> even more awesome.
> 
> I'm all for making glog cool. But I disagree about aligning it with log.
> People are going to continue to expect feature parity with log where it
> makes sense. And the current implementation of log is horrendous to the
> point where it's no longer maintainable. By being reimplemented in terms
> of revsets, I think graphlog has already passed it up.
> 
> Check this out:
> 
> $ time hg log -b stable -q | wc
>   1238    1238   23481
> 
> real	0m2.564s
> user	0m2.413s
> sys	0m0.100s
> 
> $ time hg log -r 'branch(stable)' -q | wc
>   1238    1238   23481
> 
> real	0m2.145s
> user	0m2.040s
> sys	0m0.073s
> 
> Revsets are faster (and much more powerful) than log's engine, and
> that's even before the optimizer has gotten the chance to do anything
> clever. The current log code wants to die, though we'll need to teach
> revsets a bit about the file fast path first.

I would just comment (to hammer home the obvious) that external programs make heavy use of log and the speed of log is directly proportional to the speed of some of the Mercurial GUI's like eg MacHg, etc.

Also visualization is a cool topic but at some point you just get diminishing returns with ASCII based terminal visualization. At some point you need to switch to real graphics, subtle color shades, highlighting, etc. Thus its quite important that Mercurial allows speedy and easy access to these things so that the data can be grabbed for higher level visualization tools.

Cheers,
   Jas

>>>>> It's kind of problematic to me that on a stock install (ie color not
>>>>> enabled), -H is a no-op. If we do something like this, it should a) have
>>>>> a meaningful non-color effect and b) have an appropriate non-color name.
>>>>> See <em> vs <i> in HTML for comparison.
>>>> 
>>>> If you don't have color enabled, you won't see -H.
>>> 
>>> Then I'd say it's too invasive of the core. Either it's general-purpose
>>> or it shouldn't be making the log core even hairier.
>> 
>> It could, for instance, use a different node character like * for
>> highlighted nodes (like we use @ today for the dirstate parents). Or
>> we could allow folks to specify a prefix to use for the next text,
>> with a default taken from graphlog.highlightprefix.
> 
> Ok, let's figure that out. Here's a plan of attack:
> 
> - come up with a display-neutral name for the feature (compare <em> and
> <i> in HTML)
> - come up with a sensible way to display emphasized changesets (or
> whatever we call them) in plain text
> - implement the color part of it
> 
> Note that whatever we do for plain text (ie prefix with a * or indent or
> whatever), we'll probably need to preserve when we turn color on to
> minimize surprise.
> 
> Just so we have a concrete proposal to discuss, here's my take on '*'
> prefixing:
> 
> o    changeset:   14183:333def42e785
> |\   tag:         qparent
> | |  parent:      14181:bf951d58b917
> | |  parent:      14182:ec5886db9dc6
> | |  user:        Matt Mackall <mpm at selenic.com>
> | |  date:        Wed May 04 08:21:50 2011 -0500
> | |  summary:     merge with crew
> | |
> | o  * changeset:   14182:ec5886db9dc6
> | |  * parent:      14160:fa2b596db182
> | |  * user:        Sune Foldager <cryo at cyanite.org>
> | |  * date:        Wed May 04 13:37:41 2011 +0200
> | |  * summary:     tests: fix deprecated use of hg debugdata/debugindex
> | |
> o |    changeset:   14181:bf951d58b917
> |\ \   parent:      14180:1123bbba278d
> | | |  parent:      14159:31ec4d7eb63f
> | | |  user:        Matt Mackall <mpm at selenic.com>
> | | |  date:        Tue May 03 22:04:23 2011 -0500
> | | |  summary:     merge with stable
> 
> There are other possibilities like adding a new column 0:
> 
>  o    changeset:   14183:333def42e785
>  |\   tag:         qparent
>  | |  parent:      14181:bf951d58b917
>  | |  parent:      14182:ec5886db9dc6
>  | |  user:        Matt Mackall <mpm at selenic.com>
>  | |  date:        Wed May 04 08:21:50 2011 -0500
>  | |  summary:     merge with crew
>  | |
> * | o  changeset:   14182:ec5886db9dc6
> * | |  parent:      14160:fa2b596db182
> * | |  user:        Sune Foldager <cryo at cyanite.org>
> * | |  date:        Wed May 04 13:37:41 2011 +0200
> * | |  summary:     tests: fix deprecated use of hg debugdata/debugindex
>  | |
>  o |    changeset:   14181:bf951d58b917
>  |\ \   parent:      14180:1123bbba278d
>  | | |  parent:      14159:31ec4d7eb63f
>  | | |  user:        Matt Mackall <mpm at selenic.com>
>  | | |  date:        Tue May 03 22:04:23 2011 -0500
>  | | |  summary:     merge with stable
> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> 
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list