Jeff King <peff@xxxxxxxx> writes: > It's nice to have an example like this, but there's much detail missing > in how the format is specified. However, this format is already > documented in the "helpers" section of api-credentials.txt, so it > probably makes sense to refer to that document. I'd do it the other way around. api-credentials.txt is in technical/, while the document we're writing will end-up in a man page, which cannot link to technical/. So, it makes more sense to move the format specification to git-credential.txt, and link to it from api-credentials.txt (now that we have a nice way to link to manpages from technical/ ;-) ). > I assume this got copied by looking at test-credential. I'd be OK with > including this feature in git-credential (and converting our test > scripts to use it, so we can drop test-credential entirely). But > probably it should not soak up all of the command-line arguments, and > instead should be a hidden option like: > > git credential --helper=cache fill > > That will give us more flexibility later down the road. Actually, this should already be possible with git -c credential.helper=cache credential fill I suspect that this feature will never be used outside tests, and if so, I don't think it deserves a command-line option. > I am tempted to suggest that this actually output the _whole_ > credential, not just the username and password. Coupled with the above > behavior, you would get: > > $ git credential fill https://example.com/foo.git > protocol=https > host=example.com > path=foo.git > username=bob > password=secr3t > > which happens to be exactly what you want to feed back to the "approve" > and "reject" actions (and it is not really any harder to parse). I like that, yes. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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