[Top][All Lists]
[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.
pgp0drtfDoCcF.pgp
Description: PGP signature