Opening Git tab sets global user.email

[michaelkuhn]

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

Whenever I open the Git tab (using Ctrl-9), Atom sets the global user.email configuration. I have explicitly not set it to prompt me per-repository (in combination with useConfigOnly). It seems to be set to the per-repository value of the current repository.

This seems to be due to https://github.com/atom/github/blob/master/lib/controllers/git-tab-controller.js#L374-L376 if I am reading that part correctly.

Steps to Reproduce

1. Unset global user.email
2. Open Git tab

Expected behavior:

Atom does not touch my global Git configuration.

Actual behavior:

Atom modifies my global Git configuration.

Reproduces how often:

100%

Versions

Atom : 1.53.0
Electron: 6.1.12
Chrome : 76.0.3809.146
Node : 12.4.0

[cvande04]

I have also been having issues with the Git tab asking me for user.name and user.email, even when my global configuration is already set (#2556). I wonder if it is the 1.53.0 update that is causing the issue?

[martinburger]

I have also been having issues with the Git tab asking me for user.name and user.email, even when my global configuration is already set (#2556).

Even worse, Atom overwrites any custom configuration.

[smashwilson]

Setting user.name and user.email with --global was an intentional choice. The git identity panel was designed to address a point of friction where, after installing Atom on a fresh machine (without a git install), most git operations would fail! This is especially jarring for new users; having to create a mysterious, unrelated-to-Atom config file before you could do anything else is not a good experience. I chose to write to your global config because the alternative is to need to re-prompt you for every repository you open, which seems to get on people's nerves just a little. It's also the most common recommendation - virtually every "how to install and configure git" guide, including ours here at GitHub, leads with a --global example.

I did think about finding a way to gracefully handle multiple git identities, but unfortunately doing that would be very complex. We have three distinct "identities" and accounts that we juggle in this package (the username and email used for git commits; the GitHub account used by git to push and fetch; and the GitHub token used for API operations) and all three can be set, unset, or changed independently. This already causes a great deal of confusion even with single accounts. Finding a holistic way to communicate and manage these is something I've thought a lot about but haven't come up with anything that I've been happy with yet.

But! Stomping on your global user.email and user.name settings when you already have repo-local settings is absolutely a bug 😅 . Fortunately it's one that's already been fixed as part of #2564, with the addition of this condition:

github/lib/controllers/git-tab-controller.js

Line 376 in 12172d2

if (newUsername !== this.props.username) {

Thanks for the reports, and I apologize for the inconvenience!

[martinburger]

Fortunately it's one that's already been fixed as part of #2564, with the addition of this condition:

Just being curious: Does the check

github/lib/controllers/git-tab-controller.js

Line 383 in 12172d2

if (newEmail !== this.props.email) {

properly handle the case "user.email not set at all" as described in my use case?

I just want to be sure that in that case, user.email does not get overwritten by some address although that config variable should remain unset.

[smashwilson]

🤔 You have it set for each individual repository, right? We're reading the config value without --global or --system flags, so it'll pick up the local override, see your identity as populated, and not write anywhere because it's unchanged... as long as the current context corresponds to an initialized repository.

You might still have problems when the current context does not correspond to an initialized repository, though. I haven't tried it, but I think in that case the git identity panel will be shown to you even though you don't want it to be. I'm not sure how to handle that case better for you, because "you haven't set your email yet" is exactly when we do want to show it. Maybe I could check for user.useConfigOnly?

[starlit-void]

In #2556 (comment), the problem is described very well, but I wanted to present the full list of incidents working together to cause this bug:

1. the plugin should never overwrite existing data in a config file (unless of course the user explicitly requested to do so)
2. the plugin should never write to any config file without the user's knowledge or consent (I observed this happening silently every time i opened a file in a git repo via Atom)
3. the plugin should never write to the global config file (unless approved by the user, on a per-instance basis)
4. and i would also add that the plugin should not be automatically installed alongside Atom without the user's knowledge.

I believe all of these points need to be addressed in order to fully resolve the incident. the above notes should apply to any git plugin, client, or wrapper. I think this particular issue is a great opportunity for the broader community to step back and consider friction-reduction measures as potentially harmful, and to resist the temptation to presume consent for the sake of convenience, especially when privacy, security, or identity are concerned.

Edit: to clarify the severity of the issue. This bug affected me in that my personal identity used for specific projects overrode my global git settings, causing commits i made in a professional setting to carry the wrong author. not only is this dangerous but it was a significant time drain as i fixed-up commits again and again (at first thinking I was somehow to blame for the wrong settings), and later as i tracked down what was causing the problem. Any one of the points above, had they been fixed, would have caused the problem to go away.

[smashwilson]

[..] to clarify the severity of the issue. [..]

Don't worry, I'm aware. That's why I spent time on this (on a holiday).

For about two years, working on this package was my full-time job. Since then I've moved elsewhere within GitHub. I've continued to do maintenance work here on occasion and even tinker with features that we wanted to do but never got to ship, because I like to, because I know that users get value out of it, and I because I use this daily myself. But that maintenance happens in my free time, and this year my free time has been heavily diminished. I'm also working solo when before I was working on a team of two or three others.

All this to say: you shouldn't interpret my responsiveness and level of engagement on this as me not recognizing the importance of fixing this (and therefore needing to be persuaded). You should interpret me engaging at all as a sign that I do take it seriously!

---

(unless of course the user explicitly requested to do so)

(unless approved by the user, on a per-instance basis)

☝🏻 I think this is the critical remaining fault here. I thought I was removing friction by making the entry fields write through to your config values directly... but in doing so, I've failed to secure sufficient user consent for a fairly presumptuous operation. (Writing values without you actively typing was worse! That was entirely unintended and is what I believe I have already corrected.)

I'm thinking that what I can do here is replace the write-through with explicit cancel/accept buttons, and clarify the dialog copy to ensure that it's clear what they do. I could even add separate accept buttons that write to repo-local or global config and improve support for per-repo identities while I'm at it.

---

4. and i would also add that the plugin should not be automatically installed alongside Atom without the user's knowledge.

This is off-topic for this issue and a much steeper demand. This would be the core Atom team's call, but I doubt they would be receptive to this.

When Atom was first publicly released, users frequently expressed surprise that GitHub had built and released an editor with only rudimentary awareness of git that didn't provide any integration with github.com. When this package was released, we announced it with some fanfare, and have ever since specifically called this functionality out on the main Atom landing page. I'm not sure that installing software developed by GitHub that interacts with git and GitHub is truly "without the user's knowledge". You're welcome to disable the package in your settings if you don't want the functionality it provides, and you're also welcome to try to convince the core team to remove it, but I'm pretty sure that meaningful integration with version control is part of the ground stakes for an editor developed primarily by a company that provides version control as a service.

---

Thanks again for pointing out the issues that are remaining to resolve here. 🙇🏻 I'm trying to carve out some time to deal with the next steps as soon as I can.

[starlit-void]

@smashwilson thanks for the care and attention. i'm glad for your response!!

today I learned that Atom was created by github .... obviously (in retrospect) it makes sense that the github plugin is installed by default. I discovered atom as a competent text editor and not a github tool, but I should have looked into that more deeply.

overall this is a very positive way to handle the issue and I appreciate it personally, and i hope it can be used as a good example for other similar issues in the future.

[mjaggard]

I have set my ~/.gitconfig to be owned by root:wheel and read-only on Mac, and yet still when I use the Git tab sometimes my Name and E-mail Address are blank and if I view my ~/.gitconfig it has been changed to being owned by me and the name and e-mail have been blanked out. I can't reproduce the problem every time.

Tested on 1.55.0-nightly0
On the previous version (1.53 release) I had the same problem but my e-mail address was left and only the name was blanked out.

[Aerijo]

@mjaggard

I have set my ~/.gitconfig to be owned by root:wheel and read-only

if I view my ~/.gitconfig it has been changed to being owned by me

I don't have anything to say about the cause, but the fact an application is able to change this file is not surprising. Replacing a file is controlled by directory permissions, so basically anything can replace that file with anything they like if the directory allows it. That's why the file is now owned by you, because it's a completely different file.