16

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?

Community
  • 1
  • 1
GlenPeterson
  • 4,866
  • 5
  • 41
  • 49
  • 3
    What you're waiting for, after the `Total` line, is the other end to come back and say "yes, I have accepted your ref updates" or "no, I reject your updates" (one reply per branch or tag update you're sending, which in this case is just the one branch). The problem is thus *at the other end*, probably due to a faulty hook. It needs to be diagnosed from that end. – torek Nov 30 '16 at 20:30
  • Since you 'nuke and paved' your repository, it is impossible to test your theory as to whether it was a piece of bad code. Like @torek said, it was probably the server side configuration. Your 'solution' is consistent with this, moreover, because when you rebuilt it from the ground up, you also rebuilt it with proper permissions, thus removing the error. I would suspect you simply had a permission error on your server, but I also cannot confirm this since you 'nuke and paved' the repository server. – oemb1905 Nov 27 '18 at 00:15

7 Answers7

12

In my case, updating from

git version 2.32.1 (Apple Git-133)

to

git version 2.37.1

helped.

On Mac, it can easily be done with one line: brew install git

Florian Kirmaier
  • 424
  • 5
  • 8
9

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
Jerry Sha
  • 3,931
  • 2
  • 23
  • 16
6

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.

GlenPeterson
  • 4,866
  • 5
  • 41
  • 49
  • 2
    As a quick test I used my phone's hotspot to test and it worked. Not sure if it's the router or the ISP, but I'm sure it's not my system/git. Thanks. – rrosa Mar 08 '18 at 07:35
  • 1
    I too have the same issue with my Dlink router. When using mobile hotspot, no problem – mahes Oct 13 '20 at 10:15
  • Well this is super depressing. I'm having this same problem, and I have an Orbi router from Netgear, but unless I've gotten a firmware upgrade recently, this has never happened to me before, even on the same router. Looking up and down this page there are all kinds of supposed causes and fixes here. I have the git version mentioned below, so I don't think it's out-of-date. Weird. It just started happening. I'd be inclined to blame GitHub, but I've used them successfully doing the same thing. I hate the weird problems. – cycollins Nov 17 '22 at 03:09
  • 1
    Very weird. I have successfully pushed to my git repo this morning. It's not working via the same router anymore. Nothing should've changed. Switching my wifi to my phones hotspot as @rrosa suggested, worked. – floriankapaun Dec 16 '22 at 16:09
4

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.

Greg
  • 561
  • 3
  • 9
  • 2
    Thanks! One note: on the server, you should be able to fix this by running `cd /srv/git; chown -R git-user.git-user newgitrepo.git` to change the group and user ownership of those files to be the git-user group and git-user user. If that works (I believe it should) I think that's better than deleting and recreating the repo. – GlenPeterson Jan 09 '17 at 15:15
  • Adding and deleting isn't a privilege issue - it's a git flow issue. Git requires (in my understanding) that the repo be created on the server before you can check it out - this is something GitHub does for you when you click to make a new repo. Also, Eclipse egit won't check out an empty repo - you have to push something on the server first. I have a script I can execute via ssh that creates a repo, checks it out, commits a .gitignore containing one line for bin, and deletes it. Then on the client, I can check it out and I have no issues. – Greg Jun 26 '17 at 18:22
  • I had the same issue and found this post. When I checked my repository on the server, I realized I had inadvertently changed its owner to root:root from user:user when I migrated the repository from /srv to a recent crypt I set up. Once I went to the server and executed 'sudo chown -R user:user path/to/repo/' I was able to push again no problem. – oemb1905 Nov 27 '18 at 00:11
2

I had a same issue, but my solution is different.

I am uploading a 1.9M picture, and the push just stopping at 80%, like forever.

What i fix this is : git push -f

And it amazingly works!

Songzhw
  • 131
  • 1
  • 3
  • 1
    got this issue again. this time, force push does not work. What I did is "git pull" first, and then "git push -f", and it works – Songzhw Jun 09 '23 at 17:18
0

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 my@email.com
        password some_password
machine git.the_service.com
        login my@email.com
        password some_password (same as above)
Peter
  • 1,110
  • 10
  • 25
0

In addition to all the answers in this thread, check what type of files you are pushing.

My case - 2 files:

  • Lightweight .jpg image
  • Heavy .pdf document

Tried solutions:

  • Update git
  • Update system
  • Re-add remote

Actual issue: Heavyweight pdf file.

Solution:

  • After removing .pdf from commit and re-attempting, everything got pushed to the server.
  • Added .pdf in a separate commit, and successfully pushed to the server.
Evil_Cheetah
  • 63
  • 1
  • 7