Github: Pushing to Git is extremely slow

Created on 22 Aug 2017  Â·  36Comments  Â·  Source: atom/github

Prerequisites

Description

Extreme slowness when pushing to GitHub from Atom using the GitHub functionality

Steps to Reproduce

  1. Open Atom
  2. Open a git project folder
  3. Make some changes
  4. 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.

papercut

Most helpful comment

Same issue

All 36 comments

I am having this issue as well.

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?

Same issue

Same issue

SAME issue!

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

Same issue for me too.

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.

I am also having the same issue with the latest atom version

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

Same issue, and yes, I'm using password protection for the key.

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.

Same issue using GitLab :(

Same Issue :(

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.

Is there any update on this? I am having the same issue.

mee too having same issue in gitlab

Same issue

FWIW: been experiencing this as well on a Pixelbook (Linux Beta Crostini container) when pushing to GitHub. Sometimes it appears to be stuck animation; as soon as I mouse over "pushing" turns to "fetch". other times I sit there hitting refresh on the repo page and truly don't see it hit for several mins.
Doesn't seem to be related to the size of the payload, either.

Interesting...
I'm experiencing this when I try to push to a network shared folder (ok, it's odd, but it's only my secondary backup) and there's not options besides network authentication.
I though that it was due the VPN I'm using, but the only thing slow is the push (copying files, RDP, etc. is normal)...

Ok, this issue is sort-of dead, but I am having the same issue. Git push in atom take >1 minute.

Same issue here, I though it was my project that have a lot of branches and stuff... But running git trace I noticed that it hangs in ssh connection. And its weird because I don't use password protection as few of you mentioned before.
Has anyone solved this?

This is where it stops:

11:08:05.293477 run-command.c:350       trace: run_command: 'ssh' '[email protected]' 'git-upload-pack '\''my_remote_gp/repo.git'\'''

I do have the same issue with a password protected RSA key, but as @bertaveira mentioned, repositioning the cursor in any file speeds up the process to normal shell git speed.
Anyway:

$ apm -v
apm 2.5.0
npm 6.14.5
node 10.20.1 x64
atom 1.48.0
python 2.7.17
git 2.17.1

$ atom -v
Atom : 1.48.0
Electron: 5.0.13
Chrome : 73.0.3683.121
Node : 12.0.0

$ uname -srvmpio
Linux 5.3.0-59-generic #53~18.04.1-Ubuntu SMP Thu Jun 4 14:58:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

EDIT: Why does the #53 in my Ubuntu release link to an issue????

Same issue persist. Firstly it takes long time to resolve unstaged changes , and git push too takes a minute. Very inconsistent behavior. If i do some edits to the same file thats under push , then git push gets completed. We can use GitHub Desktop if in case we are going with https with git credentials and if SSH then go for any BASH client

Was this page helpful?
0 / 5 - 0 ratings