On Tue, Oct 04, 2011 at 10:13:33AM -0700, Junio C Hamano wrote:
> Now, I would like to start moving the core part of the credential helper
> series to 'master'. Could people summarize what the current status of
> various moving parts are?
>
> Here is an example of write-up, based on my understanding (I said it
> should be pretty-much ready, but please correct me if I am mistaken).
>
> - The core part have seen some updates while it was cooking in 'next',
> with help from inputs by credential plug-in authors. The API and the
> sample implementation should be stable enough that it can be given to
> people who follow 'master' perhaps with 'experimental, minor details
> still subject to change' label attached.
No, sadly I don't think we're there yet. 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.
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.
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. I'm
not sure how much we want that. I thought some systems might find
that more natural, but that's debatable. Jay implemented a git-like
pure-terminal prompt in his helper. Lukas used the kde
password-dialog for the KDE helper. I'm not sure what people really want.
I can produce patches for both if we want to see what they would look
like. But I kind of think it's not a matter of "what will the code look
like" (both of them are pretty straightforward to implement), but "what
do we want the interface to look like". And that is really as much up to
me as to people who are going to write and use the helpers.
-Peff
--
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