Re: [PATCH_v1] add 'git credential' plumbing command

Jeff King [off-list ref] 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/

On Mon, Jun 11, 2012 at 08:02:06PM +0200, Matthieu Moy wrote:

Jeff King [off-list ref] writes:

quoted

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/.

We do so already in a few places:

  $ cd Documentation && git grep 'link:technical/'
  git.txt:link:technical/api-index.html[GIT API documentation].
  gitcredentials.txt:link:technical/api-credentials.html[credentials API] for details.
  user-manual.txt:found in link:technical/pack-format.txt[technical/pack-format.txt].

I think the rationale is that you would have the HTML documentation
installed into /usr/share/doc/git-doc or similar, and asciidoc does
correctly generate footnote references from those links. However, I
would be fine with putting the meat of it into git-credential, and
having api-credentials refer back to it. It's easier on the user that
way.

quoted

  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.

Yeah, that is even better. The tests could also use test_config.  I
would pick whichever of the two is more convenient for a particular
test.

-Peff