Re: [Monotone-devel] Questions pertaining Eclipse Integration

[Nathaniel Smith]

On Sat, Oct 28, 2006 at 09:59:35PM +0200, Ulf Ochsenfahrt wrote:
> Hi,
> 
> I'll try pasting together the answers from Richard and Timothy.
> 
> >- How does monotone select a (default) key to sign?
> 
> Richard:
> >If you only have one private key, monotone will choose it (I think, I
> >haven't tested that for a while).
> >If _MTN/options has a key identity in it, monotone will choose that.
> >Otherwise, you specify a key identity once, and its identity will be
> >saved in _MTN/options.
> 
> So basically, I first have to check mtn automate keys, and check if more 
> then one private key is returned. Additionally, I have to check mtn 
> automate get_option key, to see if a key was set for the particular 
> workspace.
> 
> That gives 6 possibilities:
> 1. no private key, no key set -> error, can't commit
> 2. no private key, key set -> error, can't commit
> 3. one private key, no key set -> private key is default
> 4. one private key, key set -> if both keys are the same, that one is 
> default, if set key doesn't exist and isn't overriden, I can't commit
> 5. mult private key, no key set -> no default key, have to choose for 
> commit with --key=
> 6. mult private key, key set -> set key is default, if exists, can be 
> overriden with --key=, if set key doesn't exist and isn't overriden, I 
> can't commit

It would certainly be possible to add some way to ask monotone "hey,
if you were going to use a key, what key would you use?"  It basically
hasn't been added yet because no-one needed it, mostly you can just
run an operation and let monotone worry about what key it uses...

What's your use case?

> >- Why is "automate get_option" not described in the manual?
> 
> It would be nice if someone wrote a description.

Yes... automate commands are supposed to be exhaustively documented.
It's a serious bug if a command has no entry at all!  However, there
may be docs in the source code that can be more-or-less copy/pasted?

> >- How can I suppress the automatic commit message dialog and get an 
> >error instead if no message was given on the command line?
> 
> --rcfile=- is a useable option, but when used with automate stdio, you'd 
> have to know all information with regard to the rcfile before the mtn 
> subprocess is started, or you have to start a new mtn subprocess, which 
> severely limits its usability for frontend integration (e.g. Eclipse).
> 
> It would be nice to have a global --non-interactive option, that makes 
> mtn always return an error instead of asking on the console/starting an 
> editor process. Alternatively, it might implicitly set this option, if 
> the stdin/stdout isn't a console.

AFAICR there are only three places that monotone prompts for input:
  -- passphrases (if get_passphrase is not set; if it is set, then it
     can prompt or whatever it likes instead)
  -- commit comment editor (actually run by edit_comment hook)
  -- merge tools (actually run by merge3 hook)

So basically you can implement --non-interactive using only hooks, if
you want... I'm not sure what you want here, though, since first you
complain about hooks being global and then you ask for a global switch
instead :-).

Again, it'd be nice to know more about your use cases -- the _easiest_
way to prevent the editor window from popping up is to just pass
"--message" or "--message-file" on the command line, and your plugin
has complete control of that :-).

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."