Wrong user credentials if mulitple entries of user.name or user.email are in config file

[chsxf]

Hi,

This issue applies to the macOS client. I'm currently using version 2.49.1 with internal git.

I have global and local credentials on many of my repositories and Fork doesn't report them correctly.
My understanding of this issue is that Fork stops at the first entry it finds in the git config --list result.

For example, git config --list will return something like this for one of my repositories:

credential.helper=osxkeychain
...
user.name=John Doe
user.email=john.doe@example.com
...
user.email=john.doe@otherdomain.com
...

Running git config user.email in my repository returns john.doe@otherdomain.com as expected.
But the General tab in the Settings for This Repository... box shows john.doe@example.com.

Thank you for your support on this.

Best of luck for this new year 2025!

[bunnyhero]

This messed up the signatures on some merge commits for me.

[chsxf]

Same here.

[DanPristupov]

Hi. What should we do to reproduce the problem? Here's what we tried:

dan@Mac FortranStdlib % cat ~/.gitconfig
[user]
        name = username
        email = user1@email.com
        email = user2@email.com
dan@Mac FortranStdlib % git config user.email
user2@email.com
dan@Mac FortranStdlib % git config --global user.email
user2@email.com

The Repository Preferences shows the correct value:

[chsxf]

Ok, so I found where the issue is.

Let say, your global credentials are user1@email.com.
I have a repository where my local credentials are user2email.com

Everything is fine in Fork until I open the "Settings for This Repository" box. The "Use global git credentials" is checked by default and the user.email config entry is immediately replaced.

I think the bug is simply that the checkbox should be unchecked if the pre-existing local email or name is different from the global one.

I've tried this several times and the credentials are replaced every time.

[DanPristupov]

I think the bug is simply that the checkbox should be unchecked if the pre-existing local email or name is different from the global one.

'Global' checkbox is checked when git config --local user.name is unset and git config --global user.name is set.

[chsxf]

It is set in my case --------------Christophe SAUVEURTel.: +33 (0) 6 87 10 10 ***@***.***________Ce message et toutes les pièces jointes sont confidentiels et établis à l’intention exclusive des destinataires.Si ce message vous parvenait par erreur, nous vous demandons de le détruire et d’en avertir immédiatement l’expéditeur par e-mail.L’usage ou la divulgation d’informations confidentielles par un tiers non autorisé est passible de poursuites judiciaires.Le 6 août 2025 à 11:16, Dan ***@***.***> a écrit :DanPristupov left a comment (fork-dev/Tracker#2270) I think the bug is simply that the checkbox should be unchecked if the pre-existing local email or name is different from the global one. 'Global' checkbox is checked when git config --local user.name is unset. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[DanPristupov]

I think the bug is simply that the checkbox should be unchecked if the pre-existing local email or name is different from the global one.

Fork shows local settings when they are defined and global settings otherwise.

I don't see a bug there. May be I'm missing something because I don't know steps to reproduce the problem.

[chsxf]

Ok, I may have made a mistake. Indeed, user.name was not set in those repositories.

However it is a use case you may want to address anyway, and maybe use two different overrides for the name and the email instead of one controlling the behaviour for the two.

Because it introduces unwanted and silent changes in the configuration of the repositories.

If user.email is not set, the box is set to use the global credentials and changes user.email to whatever is set globally without notifying the user. To keep your actual behavior consistent, it should add user.name instead, imho.