Re: [Monotone-devel] pretty pretty pictures (for some value of pretty)

[Derek Scherger]

Nathaniel Smith wrote:
> So Jack Cummings asked on IRC yesterday about tools for drawing ASCII
> revision graphs, and I, of course, said that I just type them by hand
> (practice helps), but it got me thinking, and...
>    http://frances.vorpus.org/~njs/nvm-heights.txt

excellent!

> This is assuming we adopt the convention that the first line of a
> commit message is a summary of the message (monotone's history

I've wondered about this a few times and it seems like it might be good.

> violates this right now, oh well).  The * vs. o thing is meant to make
> it obvious what is on mainline vs. what is not -- the idea being that
> * is used for revisions that are in your current branch, o for
> revisions that are not.

generally I think I'd like log to stay on-branch so the * vs o thing
might not be needed.

> It's a little cluttered, maybe we want to put blank lines between
> annotations?
> 
> *   more notes on DNS stuff (address@hidden)
> |       8517a0622bbe in org.vorpus.chryn
> |
> *   merge in async resolver (address@hidden)
> |\      62c1ff933236 in org.vorpus.chryn
> | |
> * | build into a .a file (address@hidden)
> | |     f4e48407d9de3 in org.vorpus.chryn
> | |
> | o use c-ares for name resolution (address@hidden)
> | |     c184f47b00090 in org.vorpus.chryn.c-ares
> | |
> | o import c-ares (address@hidden)
> |/      bbe06ff7eefc3 in org.vorpus.chryn.c-ares
> |       tag: t:import-c-ares-1.04
> |
> *   update docs (address@hidden)
> |       1835a700e6e6 in org.vorpus.chryn

yup, that seems better

> Lots of options.  Is this kind of layout useful?  It seems like an
> _excellent_ way to get users "thinking in monotone", i.e., thinking
> in terms of a dag-of-tree-snapshots, even if they skipped over the
> "concepts" section of the manual.
> 
> I'm not sure if this is the right summary information -- anything else
> that should be added?  Is showing a shorter form of log by default

dates might be good

> the right idea?  (Presumably you could use 'mtn log --full' to get
> something more like what we have today.)  Maybe the revid could be
> deemphasized a bit.  Maybe keyids should be listed next to branches,
> rather than next to the commit message summary?

perhaps revid/date/key/branch but that might be getting a bit long

also, perhaps rather than "log" this output comes from a different
command like say "trace" or something.

> created if you hit "commit" in the current workspace?  Seems like it
> would be better to show this with old revisions on top, new ones on
> the bottom:

yup. these are all great ideas!

Cheers,
Derek