github
github copied to clipboard
atom
Pushing to Git is extremely slow
Prerequisites
- Have you tried to reproduce the problem in Safe Mode? Yes
- Have you followed all applicable steps in the debugging guide? Yes
- Have you checked the FAQs on the message board for common solutions? Yes
- Have you checked that your issue isn't already filed? It's was filed here
Description
Extreme slowness when pushing to GitHub from Atom using the GitHub functionality
Steps to Reproduce
- Open Atom
- Open a git project folder
- Make some changes
- Stage, commit and try pushing from within Atom
Expected behavior:
Pushing with git push from the terminal takes less than 5 seconds.
Actual behavior:
Pushing in Atom takes several minutes.
Reproduces how often:
Always
Versions
$ atom --version Atom : 1.19.2 Electron: 1.6.9 Chrome : 56.0.2924.87 Node : 7.4.0 $ apm --version apm 1.18.4 npm 3.10.10 node 6.9.5 x64 python 2.7.12 git 2.7.4 OS Linux Mint 18.2
Additional Information
It is noted that pushing eventually does occur, however nowhere near as quickly as it does from a terminal.
I have the same problem with an older version of Atom. $ atom --version Atom : 1.18.0 Electron: 1.4.16 Chrome : 53.0.2785.143 Node : 6.5.0
$ apm --version apm 1.18.3 npm 5.3.0 node 8.4.0 x64 python 2.7.13 git 2.14.1
Hm, that's really odd. I would expect it to take around the same amount of time as the terminal. @smashwilson do you have any thoughts? Could it be related to one of the shell wrappers you think?
I just updated to 1.24, haven't used it yet but this is still affecting current versions? wow
Could it be related to one of the shell wrappers you think?
That's certainly my guess. I know that spawning processes is substantially slower on Windows than it is on MacOS or Linux but 5 minutes seems really excessive.
- Does this occur for both https and ssh remotes?
- If you enable "Git Diagnostics" in the GitHub package settings, can you paste the output of the push command? You won't be able to see where it's stalling because we don't show stdout and stderr until the command completes, but git's trace output does prefix lines with timestamps which might help us narrow the problem down.
I guess I'm in the wrong forum. I'm actually facing the same issue, but within linux terminal when I try to 'git push'.
@guiemi Running git with the environment variable GIT_TRACE=1 might help you figure out what the delay is :smile:
@smashwilson I don't know how to do this, I've never ran Git with Atom, although Atom is my main text editor.
Oh, I meant on the command-line. GIT_TRACE is a git diagnostic feature, not an Atom one.
$ GIT_TRACE=1 git status
09:59:20.600202 git.c:344 trace: built-in: git 'status'
On branch aw-circleci-2.0
Your branch is up to date with 'origin/aw-circleci-2.0'.
nothing to commit, working tree clean
Oh I'm sorry.
This is my output:
12:50:15.133500 git.c:344 trace: built-in: git 'status' No ramo master Seu ramo está à frente de 'origin/master' por 12 submissões. (use "git push" to publish your local commits) nada a submeter, diretório de trabalho vazio
I'm experiencing the same issue. Any updates? Btw, I found that hovering the cursor over the github bar during the push process seems to somehow fasten the process.
same issue... For me it sometimes takes 10 minutes and sometimes it just keeps going forever
Same issue
pm@abc:~$ apm --version apm 1.19.0 npm 3.10.10 node 6.9.5 x64 atom 1.25.0 python 2.7.12 git 2.7.4
One more detail I can add. This happen with me on Ubuntu 16.04. I use VirtualBox virtual workstation to run it.
As I see the issue reported almost a year ago, and I cannot get from this thread was it reproduced by Atom team and will it be possible to fix (or at least some plan about that). Can anybody clarify?
I noticed something interesting. If while it is pushing I scroll and change the cursor in a file that is pushing it goes really fast. If I just wait without touching it doesn't push at all. I am using it in cent os 7 in virtualbox
You know, now I'm wondering if this is related to the test flakiness we've seen in the GitPromptServer tests, like #1081.
As far as I can tell from looking into that in #1333, we're having issues with Windows buffering and not delivering data that we write to the named pipe used to communicate between our credential helper script and the parent Atom process. On macOS and Linux, we can close each side of the domain socket when we're done writing to it to force the buffered data to flush, but on Windows this doesn't work: the data is just dropped.
We might be able to use a TCP socket instead of a named pipe and have better luck?
For those having this issue, try using RSA keys (any size) as the method of auth w/ github. I was using a password protected ED-25519 key and pushing/pulling would take ~5mins, now I'm using a 16834-bit RSA key (not passwd protected) and it takes <30 secs.
EDIT: Adding password protection to keys seems to trigger the bug
I'm not sure if I'm seeing the same bug, but I'm using Atom with an internal git repo (actually bitbucket), using keys not passwords, running Atom on Linux.
When I click the [Push] button, it changes to the animated [⬆ Pushing] state - and gets stuck in that state for a couple of minutes - but it's already done the push. If you run git status on the command line in that folder, the push has already happened - it just seems like the button gets stuck in the animated [⬆ Pushing] state for a few minutes. This also means that you can't use the Git panel until it thinks it's finished, which is annoying.
I was migrating from bitbucket to github. I deleted the .git and git init again. I lost the history but I don't care. The history still on bitbucket.. Actually the huge size of .git folder was the problem.
When I click on push same thing happen to me. If I press right click on push and then press push in dropdown, Atom pushes in a few seconds..
Don't know why but it worked for me.
