[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch |
Date: |
Thu, 8 Mar 2007 00:08:50 -0800 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Wed, Mar 07, 2007 at 09:45:26PM -0700, Derek Scherger wrote:
> 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.
Good point.
> 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?
In this particular case, the mental model is that "branch" is always
for switching your workspace to be in a particular branch. Just,
there are two ways you might accomplish that single task -- by
switching your workspace over to the existing branch, or by creating a
new branch where you are. So a switch tells mtn how to go about
performing the command you requested, while a subcommand gives a
totally different command that just happens to be in some broader
category.
> 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.
[snip]
> 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.
Hmm, don't like this much personally. Sub-sub-commands seem like
something we should try to get rid of, whenever possible. They're
very tempting from our point of view as developers, because it's
always easy to just add another layer of grouping, but for users
they're clunky and weird. (And, if you need them at all, then you
probably have too many commands and should refactor your UI model to
involve fewer concepts.)
They're reasonable for some stuff (e.g., most of the stuff under
'db'), but exactly because those are the tools you don't need hanging
on your belt, it's okay to have to go open the tool box and look
around for them.
> Would a wiki-page that tries to group and re-phrase most or all existing
> commands into something like this help?
Generally speaking, yes, though I guess we would need to actually
agree on what the target was :-).
Existing commands in your categories 3 and 4:
privkey, pubkey: 'privkey' is already the dispreferred interface to
get a private key (easier to just copy around
~/.monotone/keys/<whatever>), and we've been talking about
dropkey: this is basically a hold-over from the past, when we were
just guessing what commands people would need... there are basically
no cases where you need this? Esp. if you can remove a private key,
again, by just going through ~/.monotone/keys directly.
chkeypass, genkey: These are real commands, but they could sure have
better names. For chkeypass, perhaps 'passphrase' (cf. passwd(1))?
For genkey, hmm, I guess it is consistent with ssh-keygen, but
wouldn't something like make-key be even better?
show_conflicts, explicit_merge, merge_into_dir, merge_into_workspace:
These are all basically temporary commands, that will all get folded
into a single 'merge' command eventually? ('merge --dry-run',
'merge -r <...>', merge + pivot_root, and just plain 'merge',
respectively?)
migrate_workspace:
Migration/upgrade commands seem like a reasonable thing to stick in
a sub-sub-command box, where people won't trip over them so much.
Perhaps 'upgrade workspace', 'upgrade db', 'upgrade
regenerate_rosters', etc.?
refresh_inodeprints: I dunno, clearly this is totally stupid UI.
cvs_import, pivot_root: These seem reasonable as is; I guess I could
see growing some sort of sub-sub-command group for other-vcs
importers, since they're used to rarely, but since we only have 1
right now... I do think we should probably use hyphens instead of
underscores, though, like everything else in the unix command line.
Suggestion: teach the command parsing code to simply replace all
underscores with hyphens when it is figuring out the names of
commands :-). (They have to stay underscores internally because
they turn into C++ symbol names, but it's easy to munge the string
on its way into the command line parsing tables.)
-- Nathaniel
--
"But suppose I am not willing to claim that. For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."
- [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Thomas Keller, 2007/03/06
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Nathaniel Smith, 2007/03/07
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Thomas Keller, 2007/03/07
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Richard Levitte - VMS Whacker, 2007/03/07
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Nathaniel Smith, 2007/03/07
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Derek Scherger, 2007/03/07
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Chad Walstrom, 2007/03/08
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch,
Nathaniel Smith <=
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Alvaro Herrera, 2007/03/08
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Nathaniel Smith, 2007/03/08
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Derek Scherger, 2007/03/08
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Derek Scherger, 2007/03/12
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Nathaniel Smith, 2007/03/12
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Derek Scherger, 2007/03/17
- Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch, Thomas Keller, 2007/03/08
- [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Bruce Stephens, 2007/03/08
- [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Steven E. Harris, 2007/03/08
- [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch, Bruce Stephens, 2007/03/08