How to resolve "remote rejected - failed to lock refs" error message?

Question

I'm kind of new to Github, so please bear me. I'm trying to push a newly updated modification of the branch from my local master repository to remote master. It has successfully committed the branch but failed to push due to the error message noted below and I'm not sure why that is as I never had problems pushing branches before. I tried some of the solutions that existed here, mostly all using different command lines but they still don't work. I'm still trying to make sense of what is the problem, why this problem is occurring and how to resolve it.

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --set-upstream origin refs/heads/master/Homepage-2017:refs/heads/master/Homepage-2017 
Pushing to https://jdoe@stash.example.org/scm/mfb/stash-web.git
error: packfile .git/objects/pack/pack-4b09cd59c424999f5712f1ea23f3198ce0b2bfb6.pack does not match index
POST git-receive-pack (532839 bytes)
remote: error: failed to lock refs/heads/master/Homepage-2017        
To https://jdoe@stash.example.org/scm/mfb/stash-web.git
 ! [remote rejected] master/Homepage-2017 -> master/Homepage-2017 (failed to lock)
error: failed to push some refs to 'https://jdoe@stash.example.org/scm/mfb/stash-web.git'
Completed with errors, see above

Answer 1

I just ran into something like this and the problem wasn't with the hierarchy but with the remote directory, bugs/, for example had a capital B, Bugs/. As soon as I specified the remote branch name to reflect the correct name I was good to go. Sourcetree, git client I use, doesn't pull branch names case sensitive so watch out for that.

Answer 2

TL;DR summary: try changing your branch name

The name master/Homepage-2017 is likely to be the culprit. Don't name any branch master/anything, ever: it's just unwise.

There seems to be something else wrong too, though, so you may want to read the rest. (See the "strange error" section in particular.)

Long detailed version

First, referring specifically to the problem called out in the title of the posting: Unless you can log in on the remote itself, and poke around there to see exactly what the problem is, there may be nothing that you can do to fix it. But sometimes we can make good guesses.

Think of git push as a coöperative process, because it is: you run git push to instruct your Git to call up another Git over the Internet-phone. In this case you have chosen to use the https protocol. (The other main option is ssh, but that's unlikely to make any real difference. It will use different authentication software, but in the end, run the same Git on the other machine.)

This https phone call carries a form of authentication—that's where this credential.helper thing comes in; it's intended to let the software on stash.example.org determine that someone claiming to be TheAmazingKnight really is you—but all that happens "outside of" the two Gits. Once they are connected on this Internet-phone-call, they just trust each other. This part is succeeding; the software on stash.example.org has let you in as you, however it goes about doing that (both the determination that your authentication is sufficient, and "becoming you" in terms of gaining permission to access and modify files, if that's necessary and appropriate on stash.example.org—that is all up to them).

At this point, your Git and their Git are able to communicate. Your Git hands over some set of commits, and then sends them a request: "I'd like you, Mr Other Git, to set your master/Homepage-2017 branch to point to commit 8bac01cafebabe0deadbeef..." (one of those big ugly hash IDs that Git shows you; this is the tip of the branch you are pushing). It's this other Git that then tries to lock the branch, and fails.

The fact that your own Git is working along normally now, and the failure is on the remote Git, is why:

error: failed to lock refs/heads/master/Homepage-2017

is prefixed by remote:. It's not your Git that is failing here, it's the remote Git, over on stash.example.org. If you want to know for sure why, you need to get more information from them, and right now you're getting everything they give you. Everything they say that's not part of the regular Git-to-Git phone call itself, your Git prints out, with remote: stuck in front. There is no knob to make them give you more information.

All that said, we can make a pretty good guess as to why this fails. What's not clear to me is how you managed to create a branch named master/Homepage-2017 on your own end in the first place.

Branch names are hierarchical

Branch names, like master and develop and bug/123, live in a hierarchical name space, much like files and directories. You can have a directory named dir and store files f1.txt and f2.txt within that directory. You can have a sub-directory of dir named d2, and have files in that directory: their names are dir/d2/f3.txt and so on.

What you can't do is have both a file dir and a directory dir. It's one or the other. The same holds for branch names: if master/ is going to be a directory, perhaps containing sub-directories, you can't have a branch named master. Likewise, if master is already a branch name, you can't have a directory master/.

Somehow—there are multiple ways to achieve this, e.g., by first renaming your existing master, or deleting your own master entirely—you have managed to give yourself a master/ directory, in which you can keep a bunch of branches, and then made one branch within that directory. But I bet that their Git, over on stash.example.org, has a master branch. As long as it has such a branch, it cannot have a master/ directory.

(It would be nice if, when Git hits one of these failures, the remote would send a message explaining this. It can, after all, see that there is a master branch blocking its ability to create a master/ directory.)

Strange error

Your output above also includes this:

error: packfile .git/objects/pack/
pack-4b09cd59c424999f5712f1ea23f3198ce0b2bfb6.pack does
not match index

(I broke it up into several lines for display purposes here—it's good to keep at as one line in exact quotes, but now that I am going to pick it apart, that's less important.) This error: is not prefixed by remote:, so that means it is coming from your Git, at the time your Git is gathering up your commits to send to their Git.

This means your Git has detected that some file(s) inside your repository database are corrupt. In particular, "does not match index" means that the pack-file index (not to be confused with "the" index: Git has chosen some very poor names...) and the pack-file itself disagree with each other.

It's not at all clear how that happened either, but it might be a good idea to clone your existing clone. This will make new pack files (and corresponding new index files) in the new clone. With any luck, those new files will be error-free, and still contain everything needed for the full Git repository database. You can then abandon the damaged clone in favor of the new (self-healed) clone. It would, however, be wise to figure out why your on-disk files on your own computer are getting damaged in the first place. (Disk drive or SSD going bad? Storing .git repositories where other things corrupt them, such as in Dropbox? Bad RAM causing in-memory cached data to become corrupt? All of these things have happened to people. The "bad RAM" case happened to me, which is why I really prefer all my machines to have ECC RAM...)