0

When I do a git push origin branch it tells me 

error: failed to push some refs to 'https://github.com/some-project...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

But when I do a git pull it moves the HEAD back to the origin branch (i.e. it removes newly created files in my local), so i then have to do a hard reset.

I read some other forums stating to do a git pull rebase (which Im not sure how it'll work) and even a git push --force (which doesn't seem like something I should get use to). Are there other alternatives to this scenario and could you elaborate or add a link?

melpomene
  • 84,125
  • 8
  • 85
  • 148
  • Just to make sure I got you, you have a repo with comments on your machine and you want to push those comments to the server repo. The server refuses your commits because you are behind the server. When you perform `git pull`, you find files deleted. Correct? – joker Jan 14 '18 at 23:12
  • first `git pull --rebase origin branch` then `git push origin branch` – Roman Marusyk Jan 14 '18 at 23:12
  • @joker correct. –  Jan 14 '18 at 23:14
  • 1
    Possible duplicate of [git error: failed to push some refs to](https://stackoverflow.com/questions/24114676/git-error-failed-to-push-some-refs-to) – Roman Marusyk Jan 14 '18 at 23:16
  • @MegaTron i tried your answer. Although after doing a `git pull --rebase origin branch` it still removes the newly created files in my local branch. –  Jan 14 '18 at 23:20
  • so, then commit them before or use staging area. Try to read git documentation – Roman Marusyk Jan 14 '18 at 23:25
  • I would stage but there is nothing to stage or even commit. I suppose I can revert to an older commit before I staged them but newer than the commit on the remote branch. Thanks for your help. –  Jan 14 '18 at 23:36
  • @plutonium244 To add a little contribution, there is no more need to use `git push --force` (especially when you don't master git). Prefer **always**, if you have to force push, `git push --force-with-lease` that prevent to do some errors by doing a check if you won't delete commits from others... – Philippe Jan 15 '18 at 00:03
  • This shouldn't be happening! If some files get deleted, this means they are not new in the commits you have created but not pushed on your machine. Moreover, deletion means that git doesn't see any changes performed on the files. Normally, git would raise conflict if you have edited a file in a commit and happened to be deleted in another commit when you pull. I just can't think of another scenario. – joker Jan 15 '18 at 00:08
  • Possible duplicate of [SSL23\_GET\_SERVER\_HELLO:sslv3 alert handshake failure](https://stackoverflow.com/questions/31113039/ssl23-get-server-hellosslv3-alert-handshake-failure) – Don Branson Jan 15 '18 at 00:08
  • @Philippe Thanks for bringing that up. I did some reading on `git push --force-with-lease`, which as you mentioned, is a much safer alternative. –  Jan 15 '18 at 20:06
  • @joker It definitely doesn't make much sense. Im no expert at git but I understand the basic commands and when I do a `git status`, it says `nothing to commit, working area clean`. Although the day before I had to clean install my mac, which after I had to reconfigure git name and email, and add origin, upstream url. I wonder if this was the reason for the conflicts. Although, the other branches are not conflicting. As you mentioned, _...edited a file in a commit [that was] deleted in another commit_. –  Jan 15 '18 at 20:23
  • I don't think this answer is worthy but what I did to work around the problem, was copy the files that were getting removed and added them to a newly created branch. I then deleted the old branch. Not the best solution if you're working with others. –  Jan 15 '18 at 20:32

0 Answers0