Thread (8 messages) flat view 8 messages, 4 authors, 2016-06-15

Re: Fwd: git clone does not respect command line options

From: Jeff King <hidden>
Date: 2016-06-15 23:08:29

Possibly related (same subject, not in this thread)

On Fri, Feb 26, 2016 at 12:15:46AM -0800, Jacob Keller wrote:
On Thu, Feb 25, 2016 at 11:59 PM, Jeff King [off-list ref] wrote:
quoted
Right. The "git-config" program doesn't know about the semantics of
particular values (remember that in the early days, there were many
porcelains which built on top of git, and they could all store their own
config). Using "--get" implements "last one wins" semantics, which
is what most config variables want. You can use "--get-all" to see all
instances of a multi-valued variable.
And note that several libraries of hooks and git extensions store
configuration there as well, not just traditional porcelain. (Though
maybe that is considered porcelain? Not really sure on the term here).
I do this myself for several custom git hooks.
Thanks, I meant to add "and it is unclear these days how many addons are
still using this feature".

I mentioned ugliness and backwards compatibility earlier.  I think
having a meaning-agnostic git-config command is still a reasonable thing
these days. But given how few multi-valued variables there are, it might
have been worth designing them differently, so that everything is
last-one-wins.

As an alternative, it would be nice to have some config syntax for
"clear the list". Maybe something like an empty string, which I think
has no meaning for the current multi-valued variables (at least not for
credential helpers or refspecs). That would allow something like:

  git -c credential.helper= clone ...

to do what you'd expect.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help