Repository navigation
Bridge credentials should be read from the full configuration chain #406
Description
git-bug does not currently read bridge credentials from anything except the user configuration file, e.g. ${HOME}/.gitconfig. It would be awesome if the full configuration chain could be supported, in order of precedence:
- Local configuration --
${REPO_ROOT}/.git/config - User configuration --
${HOME}/.gitconfigor${XDG_CONFIG_HOME}/git/config - System configuration --
/etc/gitconfig
Additionally, following include directives would be useful -- the main application for which is likely keeping the authentication configuration out of the default user-scoped conffile which is stored in a repository for public sharing.
Activity
MichaelMure commentedon Jun 17, 2020
So git-bug read the git config with git itself, through the
git configcommand.Bridges configurations are stored in the local git config (
--localis added to the command).Bridges credentials are stored in the global git config (
--globalis added to the command).Based on this, you should be able to use whatever git foo or files as long as it works for git itself. Isn't that the case ?
[-]Bridge authentication should read from the full configuration chain [/-][+]Bridge credentials should be read from the full configuration chain [/+]sudoforge commentedon Jun 17, 2020
I updated the description and title of this issue for additional clarity.
Yes, the configuration for bridges is read from the local configuration, and credentials are read from global. This issue pitches that credentials should be read from the entire chain.
sudoforge commentedon Jun 17, 2020
Also, note that there is a bug with the way credentials are read from the global configuration. If my global configuration contains a block like:
and
~/.gitconfig.foocontains thegit-bugcredential configuration, then you end up getting:MichaelMure commentedon Jun 17, 2020
But why is that the case ? Can you read those with the git config command ? git-bug doesn't do anything special there.
sudoforge commentedon Jun 17, 2020
Yeah, if you have the follow file structure:
~/.gitconfig~/.gitconfig.localthen
git config --get foo.barreturnsbazas expected, however explicitly defining--globaldoesn't follow theincludestatement and thus will return an empty value.sudoforge commentedon Jun 17, 2020
git-bugshould probably not care about where the credentials are coming from and rely upon Git's configuration loading by simply calling:instead of explicitly calling
--global,--local, or--system.sudoforge commentedon Jun 17, 2020
I don't have time to familiarize myself with the codebase today, but this is a fairly trivial patch (if you approve of it) and I'd be happy to take care of this over the next few days / weekend.
MichaelMure commentedon Jun 17, 2020
I'm torn. This looks like a git bug really, because
~/.gitconfig.localin your example is still the global config right ? So those entries should show up.One thing that could be done is to use
--globalwhen writing but not for reading, but that blur the line between local and global config. That could lead to other bugs.Some pointers:
https://github.com/MichaelMure/git-bug/blob/master/repository/config_git.go
https://github.com/MichaelMure/git-bug/blob/master/repository/git.go#L37-L45
I want to eventually migrate to using go-git instead of relying on the command line (git-bug would directly interact with the repo instead of running git commands) so this problem might just be irrelevant in the future.
MichaelMure commentedon Jun 17, 2020
Also, storing credentials in the git config might just be a bad idea: #327
sudoforge commentedon Jun 17, 2020
Agreed re: #327
It's not really a bug in
git-- using--globalor--localare specifying a specific file. You can follow includes by using--include:Although, again, I think removing the file specification altogether makes the most sense.
MichaelMure commentedon Jun 17, 2020
So just adding
--includewould work for now ? That would be trivial to do.sudoforge commentedon Jun 17, 2020
That would do it, yes, but I'd suggest removing the
--globaland--localflags when reading instead. This is, in my opinion, a much more idiomatic way to parse configuration values, as well as allowing the user to manage where their configuration is stored.For writes, writing to the global configuration is probably fine. Better yet, we could allow a flag to choose a particular configuration file for writing (e.g.
--global,--local,--file <path>).MichaelMure commentedon Jun 23, 2020
@sudoforge actually this has already been done with #371 but no released version include it yet.
That said, I'm looking at migrating to go-git instead of launching CLI commands. One of the limitation is that go-git doesn't support includes. I opened an issue at go-git/go-git#110
MichaelMure commentedon Nov 20, 2022
Closing as it's now outdated.
git-bugnow use go-git and doesn't use the git config for credentials anymore.