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

[Nathaniel Smith]

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."