monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch


From: Derek Scherger
Subject: Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch
Date: Wed, 07 Mar 2007 21:45:26 -0700
User-agent: Thunderbird 1.5.0.10 (X11/20070304)

Nathaniel Smith wrote:
> That said, I'm not stuck on branch --go; but we do need some solution
> to these problems.

This feels like an yet another new style of commands to me and I think
we already have too many.

We currently have:

-- Single word commands that take options and arguments, which are
   generally paths like mtn add, mtn drop, mtn commit, etc. These feel
   like "normal" commands to me.

-- Sub-commands commands that take various types of arguments which are
   sometimes represented as options in other commands like db info,
   db check, automate, attr get/set, etc.

-- Multi-word commands that are jammed together with underscores
   like show_conflicts, explicit_merge, merge_into_dir

-- A second form of multi-word, abbreviated commands like chkeypass,
   pubkey, privkey.

So when I say this "represents a new style", what I mean is that 'mtn
branch --go' could also be 'mtn branch go' or something and why pick one
over the other?

The single word commands feel most natural, but clearly we have too many
commands to fit everything into that form and we'll be off searching for
interesting new words to accommodate everything.

The sub-command style of things seems like something we should explore
further and I think branches should be able to fit into this well
enough. i.e.

        mtn branch create ...name...
                -- create a new branch from the current revision

        mtn branch switch ...name...
                -- switch workspace to the head of another branch)

        mtn branch continue ...name...
                -- continue this branch from the current revision

        mtn branch list [...glob...]

I'm not sure if these names are any better but in general it seems like
a consistent command/sub-command style of things would be good. The
workspace commands commit, update, add, remove, rename etc. could and
probably should stay as they are but could also be considered short-cuts
or sub-commands of a "workspace" command group.

Would a wiki-page that tries to group and re-phrase most or all existing
commands into something like this help?

Cheers,
Derek




reply via email to

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