I was in need of using different signing keys (but same mail address) and had a little adventure in the advanced Git documentation I'd like to share.
In your `~/.config/git/config`` remove the [user] section and add this instead:
[includeIf "hasconfig:remote.*.url:https://your-remote-url/**"]
path = ~/.config/git/user_a
And in ~/.config/git/user_a
use this:
[user]
email = username@example.com
name = User Name
signingkey = the_16_digit_GPG_key_ID
Repeat as often as you need. Just add another includeIf
section for each of your remote hosts.
You can also keep a “stub” user section in your ~/.config/git/config
if you always use the same user name and mail address but want to use different keys.
[user]
email = dirk@0x7be.de
name = Dirk
In your includeIf
’d files simply set the signingkey:
[user]
signingkey = the_16_digit_GPG_key_ID
Git automatically combines the two as needed.
A minimal working example:
File ~/.config/.git/config
:
[user]
email = username@example.com
name = User Name
[commit]
gpgsign = true
[tag]
gpgsign = true
[includeIf "hasconfig:remote.*.url:https://hostname_A/**"]
path = ~/.config/git/config-A
[includeIf "hasconfig:remote.*.url:https://hostname_B/**"]
path = ~/.config/git/config-B
File ~/.config/git/config-A
:
[user]
signingkey = 16_digit_key_id_used_for_a
File ~/.config/git/config-B
:
[user]
signingkey = 16_digit_key_id_used_for_b
Now when you push commits or tags to hostname_A
or hostname_B
the correct key is used to sign those (in the example, using same name and mail address) without having to manually edit this for all your local repositories.
I can't help but feel overwhelmed by the sheer complexity of self-hosting modern web applications (if you look under the surface!)
Most modern web applications are designed to basically run standalone on a server. Integration into an existing environment a real challenge if not impossible. They often come with their own set of requirements and dependencies that don't easily align with an established infrastructure.
“So you have an already running and fully configured web server? Too bad for you, bind me to port 443 or GTFO. Reverse-proxying by subdomain? Never heard of that. I won’t work. Deal with it. Oh, and your TLS certificates? Screw them, I ship my own!”
Attempting to merge everything together requires meticulous planning, extensive configuration, and often annoying development work and finding workarounds.
Modern web applications, with their elusive promises of flexibility and power, have instead become a source of maddening frustration when not being the only application that is served.
My frustration about this is real. Self-hosting modern web applications is an uphill battle, not only in terms of technology but also when it comes to setting up the hosting environment.
I just want to drop some PHP files into a directory and call it a day. A PHP interpreter and a simple HTTP server – that’s all I want to need for hosting my applications.
@Dirk
@lemmy.ml