marcosnils
FR: Allow using Github Tokens from `gitconfig` files
git config retrieves configuration values from its default config files (see man git-config) using section.key syntax and previously set also with git config.
Examples:
https://github.com/mhayashi1120/yagist.el/blob/master/README.md#config
https://www.spacemacs.org/layers/+source-control/github/README.html#git-configuration
Git takes care of choosing/finding the proper file according to OS/user/system global,etc.
It would be great to allow bin to read the token from a bin.github-token section key.
Also, Git credential helpers might come handy (although I've not used it, so far).
TIL that adding PAT's in the gitconfig is such a thing. Is there any other source I can ready about this a bit more? I find ir surprising that neither the github docs or the gh CLI mention anything about storing the token this way. In fact, the gh CLI suggests using the GH_TOKEN or GITHUB_TOKEN variables here: https://cli.github.com/manual/gh_help_environment
Aside from the mentioned Emacs packages (which use git config --global shell calls), I've looked at my own gitconfig and found sections:
[tig]: https://jonas.github.io/tig/doc/tigrc.5.html
[github]: I guess it belongs to gh Github CLI
[gitlab]: Ditto for glab (I can't remember for sure, not checked myself, just guessing)
[delta]: A syntax-highlighting pager for git, diff, grep, and blame output
Also, libgit's C API features gitconfig functions, so I guess it's a pretty widespread practice. It's also very convenient, since you can centralize all your global Git tooling config in a single file and also repo-local configs. You can also do some fancy conditional including (e.g. depending on your current dir).
HTH.
@pataquets as bin rely on "github/lab" api and not git "protocol" is this issue still revelant ?
I guess so, @ahmet2mir, since loading configuration options it's an independent task/step for the program, independent of which protocol/source you use. Even more, as gitconfig is capable of complex configurations (even conditional ones), this would ensure configuration can keep up with and accomodate future features. E.g. I have several git-related programs storing/reading their configurations from gitconfig files, be it Gitlab, Github or standalone tools.