Repository navigation
Disable locking (observe only by default) #961
Description
I prefer doing my commits and pushes from the terminal, because for instance I can use my template for commits in terminal, where the plugin just adds simple commit messages. But when the plugin is running, even if I only use it to observe, or not visible at all, it creates a .lock file in the .git folder which prevents me from doing anything in the commandline. When I remove the lockfile, it gets recreated by the plugin. Since Atom now installs this plugin by default this is a problem. Simple solution for now was to disable the plugin completely, because closing atom for a commit doesn't work for me. A good solution would be to be able to observe by default and only when you want to use its staging, committing, pushing, whatever feature that requires that lockfile, that you actually need to tell the plugin you want to use it. I don't want to be forecd to soly use this plugin. I don't mind it being installed and running in the background and use it for simple commits.
Activity
BinaryMuse commentedon Jun 21, 2017
@Anillusion What file is getting created in the
.gitfolder? Is itindex.lock?Anillusion commentedon Jun 21, 2017
Had to look it up in my terminal history but yes, index.lock.
I'm sorry if I offended anybody for not using the template, I'm still quite new at github commenting. Also, I'm in the middle of a huge development project, this is why I turned off the plugin for now and didn't provide steps to reproduce. I wanted to get rid of the issue and move on with my work, but also let you know about what I experienced. Thanks :)
BinaryMuse commentedon Jun 21, 2017
Okay. This file is placed there by Git when it runs
status, so it's actually the observing (and not the writing!) that's creating the lock file! That said, there are a few things that are interesting here:index.lockfile should be deleted by Git once thestatuscall finishes. How long does it take forgit statusto run in the repository you saw this behavior in? (If you're on a macOS/*nix system, the last line oftime git statuscould be helpful)statuscalls (by several seconds) when the app loses focus, so the app stays up to date in the background, but there is a delay of several seconds. It's possible that Git operations are taking long enough that our timer isn't long enough.I'm curious about the following:
index.lockfile eventually go away?statustake to run in this repo?Anillusion commentedon Jun 21, 2017
That might explain it then.
• I'm using a mac (OSX Sierra, 10.12.5) as my workstation, but I'm connected through samba (v4.3.11-Ubuntu) to my testserver, which is an older machine that runs Ubuntu Server 16.04.02 LTS.
• I will test it again during my commits the coming days. My experience was that doing the git status on the terminal was fast. The index.lock file didn't disappear after a while, I had to manually delete it.
• I do have linter plugins installed, I usually close the files I'm done with before committing though, but I will keep an eye out for that.
Thanks again, I will get back to you if I have more information.
viddo commentedon Jun 30, 2017
Just wanted to chime in that I observe the same issue.
Disabled this plugin for the time being which seems to make the err go away.
I'm also using mac (OSX Sierra, 10.12.5).
Yes, it appears to happen "randomly". Usually the lock file is removed after a few seconds.
Not that I'm aware of. Using some linter plugins in Atom (linter, linter-ui-default).
Any recommended way of checking this?
My git repo I work in is fairly big ("monorepo", ~4GB), but the git commands are usually fast enough:
adampope commentedon Jul 6, 2017
I'm experiencing this issue when using atom as my git editor and performing a
git rebase -i. The rebase todo opens in a new atom window, I make my changes and close the window to perform the rebase, atom then returns to my project window. However, the rebase fails with the error:fatal: Unable to create '/Users/adampope/project/.git/index.lock': File exists.I'm guessing that when atom switches back to my project window it tries to get the current git status, whilst the rebase is simultaneously happening in my terminal, creating the lock conflict. If I set my git editor to vi then the rebase succeeds.
My repo isn't very big ~100Mb.
git statustakes 0.05s.OS X 10.11.6, atom 1.18
agarciamontoro commentedon Jul 20, 2017
In case it helps: I'm experiencing the exact same issue than @adampope, but I'm using emacs as the git editor and the error persists.
I'm on Arch Linux, Atom 1.18.0 x64,
git statustakes 0.745s.UziTech commentedon Jul 20, 2017
I am running into this issue when I use
context-gitwith thegithubpackage enabled.It seems like there is a race condition between the two packages.
UziTech commentedon Jul 21, 2017
It seems like this is affecting other git packages.
When another git package runs
git addthengit committhegithubpackages detects the status change aftergit addand it becomes a race to see whethergithubcan run agit statuscommand or the other git package can rungit commitThe GitRepository class in atom seems to get around this issue but I'm not sure exactly how.
Could we add a setting to delay status checking more?
719media commentedon Jul 28, 2017
I'm running into this problem as well and I use virtualbox mapped to a drive on my mac. Basically, over time, the lock file ends up being created and never removed, and I'm not sure why. So occasionally I will have to manually delete the lockfile, or quit Atom, so be able to commit or run git commands from the command line. To answer the above questions from @BinaryMuse
*Running Atom on OS Sierra, mapped drive to virtualbox CentOS over samba
*Often, the index lock will go away within a second or two when I run into this problem. Sometimes, it will never go way and I have to quit Atom, and then manually remove the lockfile myself as a last resort.
*No processes in the background should be doing anything with git, other than Atom and my manually running of commands
*status takes 0.024s
joshribakoff commentedon Aug 1, 2017
I'm having this issue as well. Particularly bad when it happens during an interactive rebase, for example. It messes up the whole rebase history & can mess up your commits. Seems like this should be an upstream feature request to git? Git should be changed to allow running multiple concurrent "git status" (one from Atom, and one from me on the CLI)
sladex commentedon Aug 10, 2017
Running into the same issue (never had this problem before github plugin were released). I prefer not to disable the plugin completely because of some of some useful features.
Might help an option which disables status calls completely when the app loses focus. This way when I am in terminal doing some crazy rebase it won't be disturbed by Atom's status calls. At least probability would be way lower.
13 remaining items
the-j0k3r commentedon Sep 22, 2017
Well isnt that simple confusing? Why would then the git for windows trip on this bug when Im doing things in terminal only, thus using Git For Windows directly?
OK, Im definitely confused.
BinaryMuse commentedon Sep 22, 2017
@the-j0k3r The built-in Git is only meant to be used internally by the GitHub package. It does not provide you with a command-line GIt. We include it so that (1) the GitHub package works even if the user does not have Git installed, and (2) so that we can carefully control the version of Git that is bundled (so we can correctly predict supported flags, output formats, error codes, etc.)
As for your second question, the "bug" is that the version of Git embedded in the GitHub package is taking the index lockfile when it runs
status. Then, when you try to run certain operations on the terminal, you're unable to because the GitHub package has locked the index. We try to avoid running Git commands when Atom isn't focused, but this strategy isn't foolproof in all cases. So it's not your Git for Windows exhibiting the bug, it's the Git inside the GitHub package — which is why the change needs to make its way to the other distributions of Git so we can include it in the package.the-j0k3r commentedon Sep 22, 2017
@BinaryMuse understood, thanks for explanation.
After a hand full altercations every day with Atom, Im starting to understand how complex it is to keep it behaving in a manner you can predict given the volume of components involved, At least you have identified the problem,
For me its starting to make me go back to using previous tools just because elementary stuff like this is long been resolved. Shame, I really love Atom and friends.
UziTech commentedon Sep 22, 2017
@the-j0k3r I feel like it's not so much that old IDEs have solved this problem but that old IDEs just don't have this functionality. It is a pain to get things working right, but at least Atom is trying.
GreenAsJade commentedon Sep 30, 2017
I'm having this problem with sourcetree and atom running at the same time.
I make a change in Atom, then go to sourcetree to commit and it fails due to index.lock.
Strange thing is I'm coming back to this dev environment after a break of some months - it never used to happen like this before.
Note that I'm reluctant to disable the git feature in Atom, because knowing which files are changed is very valuable, but sourcetree is definitely better for looking at the repo state overall.
UziTech commentedon Oct 1, 2017
@GreenAsJade disabling the
githubpackage won't disable all the git features just the github dock pane.the-j0k3r commentedon Oct 1, 2017
@UziTech git (both Linux and Windows) works just fine fine for years and years( where this is concerned) , Even the old GitHub for Desktop App heck even the new, take a pick there's no shortage of tools using Git that dont stumble on this bug, ever.
UziTech commentedon Oct 2, 2017
@the-j0k3r I was referring to Atom making an easily hackable editor. No other text editor makes it as easy to create an IDE from it.
This git issue has a very simple fix right now, disable the
githubpackage, since the issue only presents itself when using git outside of thegithubpackage this shouldn't be a problem for most people.If you still want to use the
guthubpackage you can fork this repo, fix the issue in your own way, and use your fork instead of the core package.I can't think of any other editors that allow you to change core functionality. Yes that does mean more things will go wrong, which is why other editors don't allow it, but again, at least Atom is trying.
the-j0k3r commentedon Oct 2, 2017
@UziTech You confuse me even further, at this moment your latest interjection is just really most confusing the actual issue from what I was explained and understood from #961 (comment)
So thank you for trying to help anyway, please refer back to #961 (comment) for my only comment regarding your latest reply..
Ill wait for more positive progress in regards to this bug report and look forward for a expert solution, since Im not.
BinaryMuse commentedon Oct 2, 2017
The proposed change to add an option to Git to disable locking has landed in Git as git/git@eaffe9c and will make its way to master. Once it's been released in an actual version of Git, we can update dugite-native and solve this issue in a complete and robust way.
We'll continue to think of ways we may be able to further mitigate the issues caused by locking the index, but the new option to Git will be the final solution.
srkaeppler commentedon Oct 4, 2017
I have also noticed this bug, which was rather annoying at first. I ended up disabling all of the internal github setting and that seemed to fix things. I like controlling git over command line - just my preference.
BinaryMuse commentedon Oct 31, 2017
The referenced fix is in version 0.8.0 of this package, which is slated to go out with the next Atom beta (Atom 1.23).
the-j0k3r commentedon Nov 1, 2017
don't create a lock file on the git watch commands