git push never finishes - only gets to Total line

Question

Expected Behavior

I edited file1, committed, and did this

$ git push

NOTICE: Only authorized blah blah blah...

Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 676 bytes | 0 bytes/s, done.
Total 7 (delta 4), reused 0 (delta 0)
To ssh://me@server:/opt/git/fooBar.git
   28ad03d..73ae492  master -> master
$

Problem

Then I edited file2 in the same project, committed and did this:

$ git push

NOTICE: Only authorized blah blah blah...

Counting objects: 10, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (10/10), 1.42 KiB | 0 bytes/s, done.
Total 10 (delta 4), reused 0 (delta 0)
^C

Notice how I had to CTRL-C (^C) at the end? That's because it never completed. This is NOT the expected behavior.

Failed Coping Mechanisms

So I:

cd ..
mv fooBar/ fooBar_bak/
git clone ssh://me@server:/opt/git/fooBar.git
cd fooBar

Edit some other text file (just added a blank line), pushed, and it worked. This means I did a successful push from/to the same local/remote repositories before and after the failed push.

But edit file2 it didn't like before? The push never completes. Same thing with file3 which it doesn't like either. I don't see anything special about these files.

Well, file2 and file3 are UTF-8 and file1 is ASCII, but that shouldn't matter. Should it?

I tried all the solutions at git push hangs after Total line but none worked for me.

I didn't really understand the output of strace -efile -f git push but nothing jumped out at me.

I waited. But this is not a big repo or a big file.

I'm using Ubuntu 16.04 with git version 2.7.4 on my machine and git version 1.7.1 on the CentOS server. I don't have msysgit, git-for-windows, or cygwin installed.

git push -u origin master didn't work either.

git config http.postBuffer 524288000 didn't make any difference.

GIT_CURL_VERBOSE=1 and GIT_TRACE=1 had no effect.

git config --global core.askpass "git-gui --askpass" didn't do anything, probably because I don't have git-gui installed.

@RonanDejhero's suggestion here: https://stackoverflow.com/a/21032615/1128668 was what allowed me to see that some files can be changed, committed and pushed and some cannot. I tried copying the changed files, changing the files manually, and making slightly different changes: no good.

On the server I did sudo chown -R me.git-users /opt/git/ but that didn't make a difference either. When I've had problems like this in the past, that seemed to help.

I did a git gc in my local repo and on the server in /opt/git/fooBar.git. No joy.

Update

I deleted my local repo, cloned, edited file2 (which git didn't like being edited before) by only adding a blank line. Committed, pushed, it worked! Then I commented out a dozen lines of unused code, committed pushed, and it worked! Could I have introduced a character or something that git didn't like?

Answer 1

It was my router?!?!?!

The biggest clue was that I tried to SFTP one of the troublesome files up to the server and it failed. I had installed a new Netgear AC1750 Smart WiFi Router Model R6400 yesterday. To fix my problem, I simply unplugged the Netgear router and plugged in my old Linksys WRT120N. Everything worked.

Weird. You'd think if I'm using a VPN from my desktop and run SSH inside of that, the router wouldn't be able to tell what kind of packet it's sending. Or that if it goofed up packets that would break everything. I don't get it.

I told Netgear about my problem and indicated that I might return the router and get something I could install open-source firmware on. Their response was along the lines of "maybe you should do that" so I did. Happily running OpenWRT on a Buffalo router now with everything working.

Answer 2

I had this behaviour for a different reason, hopefully this answer helps someone else :)

I have a directory on my local git server at home at /srv/git for all my git repos, and user named git-user who owns all the files. I see URLs like ssh://git-user@server/repo to clone the repos and make changes, guaranteeing that git-user owns all the files.

I've been switchng from SVN to GIT for each of my repos. My flow for making a new repo from the latest files of an SVN repo (I don't care about the history, they're just personal projects) is as follows:

ssh <git server>
su -
su - git-user
git init --bare newgitrepo.git
exit

# Back to my desktop
cd git
git clone ssh://git-user@<git server>/srv/git/newgitrepo.git
cd newgitrepo
# Set up initial files - my local Workspace dir is where Eclipse has
# SVN projects already checked out
cp -r ../Workspace/<svn repo>/* .
cp ../Workspace/<svn repo>/<hidden dot files/dirs, except for .svn> .
# Create .gitignore files for stuff like compiled code directory
git add <everything but .git dir>
git commit -m 'Initial Import'
git push origin master

I had a case of one repo that I just couldn't push anything without getting this irritating behaviour of a total line and no further response. I had missed the 3rd command on the server (su - git-user), so I had created my bare repo as root, causing all files to be owned by root. The solution of course was just delete the bare repo on the server and re-create them as git-user.

This lines up with what GlenPeterson said about this being a server problem, and not a client problem.

Answer 3

I just had this exact issue but the cause was different. The origin using

git remote -v

result: origin pi@raspberrypi:/home/git/...git

I had a user that didn't have write access on my git repo.

The fix was to remove and re-add origin with the correct user

git remote rm origin
git remote add origin git@raspberrypi:/home/git/...git

Answer 4

I had this problem while pushing to a git remote of gigalixir. The problem was that their CLI failed to save the password necessary for pushing to my ~/.netrc file. So, if you push to a git remote over https, please check that your ~/.netrc file contains something like this:

machine api.the_service.com
        login [email protected]
        password some_password
machine git.the_service.com
        login [email protected]
        password some_password (same as above)