Bridge credentials should be read from the full configuration chain

sudoforge opened (edited)

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}/.gitconfig or ${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.

Michael Muré (MichaelMure) commented

So git-bug read the git config with git itself, through the git config command.

Bridges configurations are stored in the local git config (--local is added to the command). Bridges credentials are stored in the global git config (--global is 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 ?

sudoforge changed the title from Bridge credentials should be read from the full configuration chain to Bridge credentials should be read from the full configuration chain

sudoforge commented

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 commented

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:

[include]
  path = ~/.gitconfig.foo

and ~/.gitconfig.foo contains the git-bug credential configuration, then you end up getting:

➜ git bug bridge {pull,push,etc}
Error: no token found for the default login "<git-bug.bridge.default.default-login>"

Michael Muré (MichaelMure) commented

But why is that the case ? Can you read those with the git config command ? git-bug doesn't do anything special there.

sudoforge commented

Yeah, if you have the follow file structure:

~/.gitconfig

[include]
  path = "~/.gitconfig.local"

~/.gitconfig.local

[foo]
  bar = "baz"

then git config --get foo.bar returns baz as expected, however explicitly defining --global doesn't follow the include statement and thus will return an empty value.

sudoforge commented

git-bug should probably not care about where the credentials are coming from and rely upon Git's configuration loading by simply calling:

git config --get <key...>

instead of explicitly calling --global, --local, or --system.

sudoforge commented

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.

Michael Muré (MichaelMure) commented

I'm torn. This looks like a git bug really, because ~/.gitconfig.local in your example is still the global config right ? So those entries should show up.

One thing that could be done is to use --global when 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.

sudoforge commented

Agreed re: #327

It's not really a bug in git -- using --global or --local are specifying a specific file. You can follow includes by using --include:

--[no-]includes
  Respect include.*  directives in config files when looking up values. Defaults to off when a specific file is given (e.g., using --file, --global, etc) and on when searching all config files.

Although, again, I think removing the file specification altogether makes the most sense.

Michael Muré (MichaelMure) commented

So just adding --include would work for now ? That would be trivial to do.

sudoforge commented

That would do it, yes, but I'd suggest removing the --global and --local flags 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>).

Michael Muré (MichaelMure) commented

Closing as it's now outdated. git-bug now use go-git and doesn't use the git config for credentials anymore.

Michael Muré (MichaelMure) closed the bug