monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'


From: Nathaniel Smith
Subject: Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
Date: Mon, 8 Oct 2007 02:13:10 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Oct 07, 2007 at 09:58:14PM -0600, Derek Scherger wrote:
> Ethan Blanton wrote:
> 
> > I believe that it should; if it is more than just a few columns wide,
> > it tends to make diffs and commit messages wrap on terminals they are
> > meant to accommodate, and it displays an unfortunate tendency to be
> > far more than a "few" columns wide.  Even when it is correct, for
> > Pidgin it often has 3-5 parallel lines at two columns apiece, and
> > often it mistakenly draws O(a lot) of parallel lines.

This seems fixable -- we know how wide the terminal is (the ticker
code needs this), we know that the graph becomes *completely* useless
when wrapping happens, so we can just teach monotone to do the Right
Thing (i.e. disable the graph when it gets too wide, perhaps only for
portions of time when it is too wide).

There are a lot of other ways that the graphs are not as smart as they
could be, and currently require --no-graph -- e.g., if you use
--no-merges (like one of the examples upthread) then right now you
basically have to use --no-graph.  So that's easy to make
right-by-default too.  The other example given was as part of a hack
to create a command that mtn should have anyway -- so when we add that
command, that need for --no-graph will disappear as well.

The graphs would also be more useful if log output were shorter (and
esp. the merge output were less completely stupid than it is now --
showing every file touched on either side of the merge makes No
Sense).

> Another thought. Maybe what we really need is something like .csvrc
> where you can specify the default options that you generally want with
> specific commands. I'm not sure how you would occasionally un-set
> options that were set like this though.

This would be an easy way to make this problem go away, but I'm not
convinced that it's the correct one.  It seems to me that the problems
with the graphs are more specific, and fixable as such.

-- Nathaniel

-- 
"If you can explain how you do something, then you're very very bad at it."
  -- John Hopfield




reply via email to

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