monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nathaniel Smith
Subject: Re: [Monotone-devel] pretty pretty pictures (for some value of pretty)
Date: Thu, 14 Sep 2006 13:22:41 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Sep 13, 2006 at 10:52:38PM -0600, Derek Scherger wrote:
> Nathaniel Smith wrote:
> > 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.

Even if the default is to stay on branch, surely this will not be the
only mode?

Also, even if it does stay on branch, you probably want to show some
dangling revisions to let people know where they could drill down?
(Though these could also be reduce to just a trailing edge, like : or
|.)  Cf. monotone-viz again...

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

Hmm, they were intentionally left out, actually :-).  I tend to feel
like they're less important than the other pieces of information here,
and in my "benign social engineer" hat, it seems a win if we can
gently encourage people to think in terms of graph structure rather
than dates.

Those are the reasons, others may disagree -- I'm probably farther
towards finding dates useless than most people.  In general, though,
leaving things out is just as important as putting them in.

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

Why?  Does log have too-standardized a meaning?  Is this not what
you'd want be default?  Umm... I don't know if it should be log,
either, but why do you say that?

-- Nathaniel

-- 
.i dei jitfa fanmo xatra




reply via email to

[Prev in Thread] Current Thread [Next in Thread]