Bug report for git push

Bug report for git push

[Surenkumar Nihalani]

Hi everyone!

I am facing this spurious issue (not easily reproducible and usually a retry fixes it) with git push:

Warning: Permanently added 'github.com,192.30.255.112' (RSA) to the list of known hosts.
Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 971 bytes | 971.00 KiB/s, done.
Total 8 (delta 7), reused 0 (delta 0)
remote: Resolving deltas:   0% (0/7)
remote: Resolving deltas:  14% (1/7)
remote: Resolving deltas:  28% (2/7)
remote: Resolving deltas:  42% (3/7)
remote: Resolving deltas:  57% (4/7)
remote: Resolving deltas:  71% (5/7)
remote: Resolving deltas:  85% (6/7)
remote: Resolving deltas: 100% (7/7)
remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
error: failed to push some refs to 'git@github.com:quora/qcore.git'
[May 12 12:14 AM remote._get_push_info] Error lines received while fetching: error: failed to push some refs to 'git@github.com:quora/qcore.git'
Push flags:  1040
Push summary: [remote rejected] (cannot lock ref 'refs/heads/master': is at cf2cc0c147d8215ec87d3ddaf32f0b2c58630423 but expected fdda486ad43a6e6b5dc5f2795ce27124e0686752)

Remote repo rejected your commit.


This is happening in git version 2.17.0

I've tried searching stack overflow and the git mailing list but the answers aren't recent enough or don’t seem to be permanent fixes.
How do I fix this issue?

Re: Bug report for git push

[Jeff King]

On Fri, May 11, 2018 at 09:44:54PM -0400, Surenkumar Nihalani wrote:

> Push summary: [remote rejected] (cannot lock ref 'refs/heads/master': is at cf2cc0c147d8215ec87d3ddaf32f0b2c58630423 but expected fdda486ad43a6e6b5dc5f2795ce27124e0686752)

This generally indicates that somebody was pushing at the same time as
you, and you lost the race. The push conversation works basically like
this:

 1. server advertise master at some sha1 (like fdda486ad)

 2. client checks that moving from fdda486ad to whatever the new value is
    (let's say 1234abcd) matches its criteria (e.g., not a fast-forward)
    and prepares a pack with the appropriate objects

 3. client tells server "update master from fdda486ad to 1234abcd"

 4. server locks master and then under lock checks that it's still at
    fdda486ad. In this case it's not, so it aborts the lock. This is
    likely due to somebody else pushing in the interim.

If you push again at this point, the client will notice in step that
it's not a fast-forward and give you the "somebody else has pushed, you
need to pull first" error message.

The only difference here is that because of the timing (i.e., somebody
pushing at the exact same time as you), only the server's locking
operation noticed the conflict. But the fix is the same (pull their
work, then push).

-Peff