monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Command aliases and removing command expansion from


From: Daniel Carosone
Subject: Re: [Monotone-devel] Command aliases and removing command expansion from monotone
Date: Thu, 15 Dec 2005 13:00:58 +1100
User-agent: Mutt/1.4.2.1i

On Wed, Dec 14, 2005 at 07:09:39PM +0100, Jon Bright wrote:
> Hi,
> 
> Richard Levitte - VMS Whacker wrote:
> >
> >I disagree with removing keyword expansion.  I agree that some aliases
> >can be added to ensure that certain shortcuts always work.
> 
> I also disagree with removing keyword expansion on the grounds that a 
> lot of the time, it's useful.  Maybe a solution would be that for 
> potentially dangerous commands, we could insist on a non-expanded 
> version.  Something like:
> 
> ~$ monotone rev
> monotone: The "revert" command must be typed in full
> 
> How does that sound?  Best of both worlds, or unwanted nannying?

i think maybe unwanted nannying; if we need to add something to make
"revert" less idiot/finger-proof, that will deal with 'rev' also.

but this makes me think of something else...  we currently have
"automate stdio", that lets a persistent monotone process keep db
startup and cache contents across individual automate commands..

what about a "monotone interactive" (or just plain monotone with no
command?) that drops the user at a monotone> prompt, takes lines of
input just as if they were in argv, and wraps readline and
tab-completion (for subcommands too) around it based on the current
expansion mechanism.

So a typical workflow might go something like:

% monotone
monotone> status
...
monotone> list unknown
...
monotone> add --unknown
...
monotone> commit
...
monotone> pull
...
monotone> merge
...
monotone> sync
...
monotone> update
...
monotone> ^D

Many of these ops would tend to hit the same data in the db each time,
and it might make things a little snappier...

It's (perhaps sadly) not something that is easily provided by a
wrapper program and/or shell completion, because the whole point is to
keep the db open across operations.

--
Dan.

Attachment: pgp0drtfDoCcF.pgp
Description: PGP signature


reply via email to

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