Read and write git configuration without repository #2564
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2564 +/- ##
==========================================
+ Coverage 93.43% 93.44% +0.01%
==========================================
Files 236 237 +1
Lines 13208 13232 +24
Branches 1900 1905 +5
==========================================
+ Hits 12341 12365 +24
Misses 867 867
Continue to review full report at Codecov.
|
|
@smashwilson I'm not seeing the v0.36.6 update available in Atom yet, and I just upgraded it to 1.54.0 to make sure that wasn't the problem. Did you remember to push the release up to the Atom Package Manager server? |
|
I didn't forget... I hit a mysterious crash trying to do the actual upgrade in atom/atom#21782 that I haven't been able to get to the bottom of yet 😞 . I'm guessing that it'll take me two or three days of dedicated time on the Windows box, which I have not been able to muster. The good news is that there's a partial fix in Atom 1.54.0 that should improve things somewhat in the meantime. |
|
#2643 to |
Reading and writing global or system git configuration entries, like
user.emailanduser.name, makes sense even if the current repository is absent or uninitialized. Let's let these calls succeed by using a git strategy initialized with a workdir of the drive root.This addresses #2558 by behaving correctly in a variety of situations where we should be able to read your identity from the global git configuration, but weren't. We prevent git commands from executing in contexts where we don't have a valid working directory to run them with - if a project root is not an initialized git repository, or if we have no project root yet, or if a git repository is still loading - but
git configdoesn't have this constraint; unless you specify--local, it's perfectly reasonable to read and write global or system git config values without a working directory. Allowing this to happen closes the windows of time during which the git tab can attempt to readuser.nameanduser.email, get empty strings back from the stubbedgetConfigmethods on those repository states, and conclude that it needs to display the identity panel to prompt you for them.I also needed to implement cross-instance cache invalidation among repositories in the
WorkdirContextPool, so that setting your identity in one context would properly cause any other repositories in other contexts to pick up the changes that you wrote (and not, for example, immediately delete them).Note that non-present repository states do not cache these config values, so they could be redundantly read frequently. I think that's okay for now because config reads are very quick. I also haven't implemented a filesystem watcher on the global configuration file to pick up external identity changes automatically.