Re: [Monotone-devel] Questions pertaining Eclipse Integration

[Ulf Ochsenfahrt]

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

Eclipse Plugin. It needs to know the key that would be used so it can 
show it to the user and allow the setting to be changed if necessary. 
It's not a high-priority issue, it just came up in my coding today.

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

There are several issues here. Most importantly, when run in the 
background, mtn may never ever ask anything. That would just hang the 
entire Eclipse IDE or whatever other frontend (happened to me today), 
and you have to kill it manually.

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

This is not just with respect to the editor window, it's got to do with 
everything (tm). Adding a global flag would make it easier to develop 
tools that use mtn in the background.

The passphrase dialog on commit is my biggest problem right now. If the 
passphrase is set in the default monotonerc, then I'd rather just use 
that. If it's not set, I have to ask the user. Jon's original code would 
always ask the user, my current code never asks. Both approaches are 
clearly wrong.

This is not solvable with hooks. If I override the passphrase hook, I 
can never use the passphrase from monotonerc. If I don't, I get stuck if 
the user doesn't provide it in monotonerc.

More generally, for correctness, I'd rather have monotone fail instead 
of ask the user in all cases, when run in the background. Now and with 
whatever extensions at whatever point in the future. That's why I'm 
asking for a global flag.

Alternatively, one could make the automate interface more powerful 
(needs at least add, drop, rename, and commit commands) and interpret 
that as --non-interactive.

For commit (and thus to solve the passphrase issue), I think the best 
solution would be to add an automate commit command that takes a 
passphrase parameter and a key parameter and a message parameter (and 
maybe a couple more) and that fails if the passphrase doesn't work, or 
no message is specified, or no key could be selected for signing.

Finally, I need to figure out which key mtn is going to use so I can 
give the user the appropriate information in the passphrase dialog.

Cheers,

-- Ulf

smime.p7s
Description: S/MIME Cryptographic Signature