Jeff King <peff@xxxxxxxx> writes: > No, sadly I don't think we're there yet. It is much better to proceed with caution than unleashing something whose semantics will later have to change so drastically that we end up hurting end users, so nobody has to say "sadly". By spelling out what more needs to be there for us to get there, we are making progress. > The two big open questions are: > > 1. Should we be giving more context details to the helpers, and/or > should we be breaking down the information into pieces? > > I think the answer is probably yes. Certainly OS X would benefit > from the broken-down pieces. My feeling is that we could hand > helpers both broken-down pieces as well as an inclusive URL. So > something like: > > git credential-foo \ > --type=network --protocol=https --host=example.com \ > --username=user1 --path=repo.git \ > --url=https://user1@xxxxxxxxxxx/repo.git > > and then the helper can pick what it likes from there. Hmm, don't we first want to enumerate contexts where we might want to get the access information from the user? E.g. * "transport" aka "git fetch/push"; I think you meant this by --type=network, but there probably are other kinds of accesses over "network". * "imap-send". * "send-email". * "tag -s" and perhaps upcoming "push --signed" or "commit --gpg-sign"? Anything else? I am not sure where the unlocking passphrase for ssl cert fits in this picture, though. > One thing I haven't figured out is how the user would tell git "no, > the repo path is not relevant for determining the auth domain". > That feature can come later, but I want to make sure that helpers > know they might or might not get the "--path" option. I guess that > is just a matter of documentation; I'm just a little nervous > committing to it without having figured out the details. Well, shouldn't the caller of credential-foo be passing --authdomain as a separate piece anyway? In the above example, if example.com operates as a single auth domain no matter what repository, --authdomain may just say "". If it uses per repository auth domain, --authdomain may say "repo.git" (I am assuming <authdomain> is not globally unique but unique within the context of <type, host> or perhaps <type, proto, host>). > 2. There has been some talk that the helper interface should perhaps > be vastly simplified from "get the credentials and give them to > git" to merely being a store/retrieve system, where the invocations > would be something like (pretend git is the shell): > > # git asks if we have a stored credential > git credential-foo --get --url=...,etc | read password > > # we had a successful authentication; ask the helper to store it; > echo password | git credential-foo --put --url=...,etc > > That makes the helpers much simpler, and makes interacting with the > user more uniform across helpers. > > It disallows helpers doing specialized interactions or dialogs. Very true. I have this suspicion that running dialog on various desktop environments may be orthogonal to what credential store to be used. Once we know the repertoire of the broken-down pieces, we may want to add "dialog-foo" family of helpers whose sole purpose is to interact with the user to get missing information. E.g. we may notice that we need to ask both the username and password, and invoke $ dialog-foo --msg=$msg --ask=username --ask-secret=password where $msg tells the user why we are asking these pieces (e.g. trying to push into https://example.com/repo.git), and then read from the helper what the user gave it. If the URL had user1@ in it, then the $msg would say that we are trying to push into https://example.com/repo.git as user1, and we invoke the helper with only --ask-secret=password (without --ask=username). The same "helper" executable _could_ implement both interfaces, but I think they are logically separate. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html