[Top][All Lists]

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

Re: [Monotone-devel] mtn cat vs. mtn automate get_file

From: Thomas Keller
Subject: Re: [Monotone-devel] mtn cat vs. mtn automate get_file
Date: Mon, 20 Nov 2006 18:55:04 +0100
User-agent: Thunderbird 1.5 (X11/20060317)

Nathaniel Smith schrieb:
> I know that we have the ability to use options in automate now, and
> this is totally an aesthetic judgement, but get_file_of the _only_
> command of its type that uses -r to specify revisions seems weird and
> inconsistent.  Maybe it would be better to make it consistent with the
> other commands for now, and then as a separate step, if there is
> consensus that we really want to do things that way, switch over all
> the automate commands to use -r at once?

Well, then why did I use options for content_diff (and that was ok), but
shouldn't use them here? IMHO I use options to separate different types
of arguments, so while its perfectly ok to have i.e.

   command REV1 [REV2 ...]
or command FILE1 [FILE2 ...]

mixing arg types like

   command REV FILE
or command FILE REV

often leads to questions like "what do I need to specify first? what
happens if they're specified differently?". For me this is more an
inconsistency of some core commands of monotone, like push/pull/sync,
which also leads to problems of the type "I can't omit the server part
if I just want to push/pull/sync a different branch!"

Of course not many automate commands use options until now, and of
course it looks a bit weird at first, but why do the work twice and
implement some pseudo cmdline interface which is later dropped anyways?
The only real problem I see with options to automate commands at all is
the bug that they're currently not displayed on `mtn automate <command>


- "I know that I don't know." (Sokrates)
Guitone, a frontend for monotone:
Music lyrics and more:

reply via email to

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