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
