GitButler not using includeIf configurations

[Kristijan]

Version

0.13.8

Operating System

macOS

Distribution Method

dmg (Apple Silicon)

Describe the issue

GitButler doesn't appear to use git configurations that are dynamically sourced in via an includeIf. I don't have the following configuration set it my default ~/.gitconfig, rather, they're sourced in depending on the remote that I'm working on.

• user.name
• user.email
• user.signingkey
• gpg.ssh.allowedsignersfile

My global ~/.gitconfig has entries like this, which then sets the respective configuration items.

includeif.hasconfig:remote.*.url:git@github.com:*/**.path=~/.dotfiles/git/gitconfig-personal
includeif.hasconfig:remote.*.url:git@ghe.work:*/**.path=~/.dotfiles/git/gitconfig-work

I get the following error when trying to commit with the above configuration.

However, if I do set those variables in either the global or repository configurations, then it works fine.

How to reproduce

As a minimum, remove the following from your global configuration, and set them via an includeIf directive.

• user.name
• user.email

Use GitButler to make a commit to reproduce the error.

Expected behavior

GitButler should use any values sourced in via an includeIf, just like git currently does. It allows the user to set different names, emails, signatures, etc... depending on the includeIf test conditions.

Relevant log output

No response

[Byron]

Thanks a lot for reporting!

hasconfig is a relatively 'recent' feature that isn't implemented in gitoxide yet. It's also not implemented in git2 so the only way to respect this today is to use git itself to read this configuration. It's probably better to wait until it's available, it's on my list now as this kind of compatibility is very important to me.

[Byron]

This is now implemented in gitoxide and will soon land here.

If everything goes well, tomorrow or in a couple of days at the latest, the feature can be tried in a nightly build.

[Kristijan]

Amazing! Happy to test once it lands in the nightly build.

[Kristijan]

Hey @Byron, are you only supporting certain configuration options that are being included with includeIf? From my quick limited testing, it appears that user.name and user.email work, but user.signingkey does not (i.e. it doesn't auto-populate the signing key in the project settings for signed commits)?

On the topic of signing keys, is it possible to have this turned on at a global level? I sign all my commits in all my projects, but right now, I need to explicitly turn it on per-project when I add a local repository. Would be nice if I could set a default in the GitButler settings to have signed commits turned on/off, and then manage, should I need to, via the individual project settings.

[Byron]

Thanks a lot for sharing your insights!

Indeed, I forgot about all the other configuration keys listed here and only focussed on user.email and user.name, which are some of the few settings that are actually read with gitoxide.

user.signingKey for example is read here…

gitbutler/crates/gitbutler-repo/src/repository_ext.rs

Line 355 in 1031de1

let signing_key = self.config()?.get_string("user.signingkey");

…which uses git2 still, so the includeIf support is very limited.

In order to fix this, one would have to use gitoxide to read all configuration, or more specifically here, offer a way to create signed commits right away.

[Kristijan]

Manually adding user.signingKey per-project is just a friction point at this stage for me that I'm willing to live with while gitoxide matures. I work in a large organisation using GItHub Enterprise, so it's not uncommon that I'm flipping between 10 different repositories in a typical work week. I'm trying to get GitButler working for me so I can get it to a point of adding a repository and it being usable without having to dive into the settings.

The other option that I set using includeIf is allowedSignersFile. I have a script that uses the GitHub API to download all the public keys from contributors, and puts them into a file that the option is pointed at. This way, I can use git show --show-signature to verify signed commits. Would be nice to see the verified check-mark in GitButler when looking at other users commits. Maybe a future roadmap feature 😄

[Byron]

Thanks a lot for holding out for us to catchup :), it's much appreciated!

This way, I can use git show --show-signature to verify signed commits. Would be nice to see the verified check-mark in GitButler when looking at other users commits. Maybe a future roadmap feature 😄

I don't think there is an issue for that yet and I welcome you to set it up :).