Junio C Hamano [off-list ref] writes:
Jakub Narebski [off-list ref] writes:
quoted
It would be nice to have an option to git-config which would do such
expansion, as a separate type similar to --int and --bool, e.g.:
git config --path section.key
so that not only core.excludesfile could use this new feature, but for
example also core.worktree, commit.template, gitcvs.logfile,
mailmap.file, and perhaps also *.receivepack and *.uploadpack
What should "git config -l" do for these (and core.excludesfile)?
I don't know what it "should", but it "does" not do the expansion. I
had the same questionning when testing the patch, I'd have liked to be
able to write a simple test-case like
$ git config core.excludesfile '~/foo'
$ git config --i-dont-know-what core.excludesfile
to go through this codepath. Maybe we can just say
$ git config --default core.excludesfile
to say "call git_default_config(...) on this before printing it". My
understanding is that this is what the C code is doing, we should
allow the shell scripts to do the same.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Dnia wtorek 17. listopada 2009 09:57, Matthieu Moy napisał:
Junio C Hamano [off-list ref] writes:
quoted
Jakub Narebski [off-list ref] writes:
quoted
It would be nice to have an option to git-config which would do such
expansion, as a separate type similar to --int and --bool, e.g.:
git config --path section.key
so that not only core.excludesfile could use this new feature, but for
example also core.worktree, commit.template, gitcvs.logfile,
mailmap.file, and perhaps also *.receivepack and *.uploadpack
What should "git config -l" do for these (and core.excludesfile)?
I don't know what it "should", but it "does" not do the expansion. I
had the same questionning when testing the patch, I'd have liked to be
able to write a simple test-case like
$ git config core.excludesfile '~/foo'
$ git config --i-dont-know-what core.excludesfile
to go through this codepath. Maybe we can just say
$ git config --default core.excludesfile
to say "call git_default_config(...) on this before printing it". My
understanding is that this is what the C code is doing, we should
allow the shell scripts to do the same.
I think it is a very good idea. Nevertheless it can apply only to
config variables git core knows about, and not for example for git-gui,
or gitk, or qgit, or tig, or StGIT, etc. configuration. Therefore
"git config --path" would be still needed.
--
Jakub Narębski
Poland