undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

credential: update gitcredentials documentation

Browse Source 
Clarify the expected effect of all attributes and how the helpers
are expected to handle them and the context where they operate.

While at it, space the descriptions for clarity, and add a paragraph
mentioning the early termination in the list processing of helpers,
to complement the one about the special "quit" attribute.

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Carlo Marcelo Arenas Belón 2020-05-06 14:47:25 -07:00 committed by Junio C Hamano
parent bb98765769
commit 4b8938be4c
1 changed files with 18 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/gitcredentials.txt
View File

@ -262,16 +262,26 @@ For a `get` operation, the helper should produce a list of attributes on
stdout in the same format (see linkgit:git-credential[1] for common
attributes). A helper is free to produce a subset, or even no values at
all if it has nothing useful to provide. Any provided attributes will
overwrite those already known about by Git. If a helper outputs a
`quit` attribute with a value of `true` or `1`, no further helpers will
be consulted, nor will the user be prompted (if no credential has been
provided, the operation will then fail).
overwrite those already known about by Git's credential subsystem.
While it is possible to override all attributes, well behaving helpers
should refrain from doing so for any attribute other than username and
password.
If a helper outputs a `quit` attribute with a value of `true` or `1`,
no further helpers will be consulted, nor will the user be prompted
(if no credential has been provided, the operation will then fail).
Similarly, no more helpers will be consulted once both username and
password had been provided.
For a `store` or `erase` operation, the helper's output is ignored.
If it fails to perform the requested operation, it may complain to
stderr to inform the user. If it does not support the requested
operation (e.g., a read-only store), it should silently ignore the
request.
If a helper fails to perform the requested operation or needs to notify
the user of a potential issue, it may write to stderr.
If it does not support the requested operation (e.g., a read-only store),
it should silently ignore the request.
If a helper receives any other operation, it should silently ignore the
request. This leaves room for future operations to be added (older