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

[Derek Scherger]

Nathaniel Smith wrote:
\> 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.

I might have just been put off by the "--here" and "--go" options as
well.  I've been playing with mdadm(8) lately and perhaps have seen a
few too many options or something.

> 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.)
> 
> 
> chkeypass, genkey: These are real commands, but they could sure have
>   better names.  For chkeypass, perhaps 'passphrase' (cf. passwd(1))?

Yeah, that one in particular seems very reasonable.

>   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?)

Yeah as I wrote my initial response I was thinking that explicit_merge
is literally merge -r aaa -r bbb or something so holding off of this is
fine for now.

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

I've typed regenerate_rosters enough times that it's starting to feel a
bit long to me. The idea of an "upgrade" category of commands sounds
good and singe regenerate_rosters is now regenerate_caches how about
"upgrade caches" or some such?

> refresh_inodeprints: I dunno, clearly this is totally stupid UI.

Yeah, something like "mumble on/off/update" would be better, for some
value of mumble, "inodeprints" is a bit of a mouthful.

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

Hear, hear. I agree with this completely. I've never liked the underscores.

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

I'll try and have a quick look into this.

Cheers,
Derek