git push says "everything up-to-date" even though I have local changes

Question

I have a remote gitosis server and a local git repository, and each time I make a big change in my code, I'll push the changes to that server too.

But today I find that even though I have some local changes and commit to local repository, when running git push origin master it says 'Everything up-to-date', but when I use git clone to checkout files on the remote server, it doesn't contain latest changes. And I have only one branch named "master" and one remote server named "origin".

PS: This is what git displays when running ls-remote, I'm not sure whether it helps

$ git ls-remote origin
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
$ git ls-remote .
49c2cb46b9e798247898afdb079e76e40c9f77ea        HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/heads/master
df80d0c64b8e2c160d3d9b106b30aee9540b6ece        refs/remotes/origin/master
3a04c3ea9b81252b0626b760f0a7766b81652c0c        refs/tags/stage3

Criollo

https://mcmap.net/q/21269/-how-to-update-application-on-heroku/343495 – Portugal

Worth double-checking you're in the right directory! Esp. when you have submodules you can mistake git responses from parent.. – Brandon

In my case I was getting error while commit which I did not notice and tried to push code – Clermontferrand

forgot to commit? – Secretarial

I have no idea how this happened, but resetting the commit (git reset), closing my console window and returning back from where I started helped me out – Dew

### Init github access git config --global user.email "[email protected]" git config --global user.name "iamgit" ### Commit git commit -am "compile" ### Push to git git push -f origin master – Semiautomatic

Answer 1

Are you working with a detached head by any chance?

As in:

indicating that your latest commit is not a branch head.

Warning: the following does a git reset --hard: make sure to use git stash first if you want to save your currently modified files.

$ git log -1
# note the SHA-1 of latest commit
$ git checkout master
# reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

---

As mentioned in the git checkout man page (emphasis mine):

It is sometimes useful to be able to checkout a commit that is not at the tip of one of your branches.
The most obvious example is to check out the commit at a tagged official release point, like this:

$ git checkout v2.6.18

Earlier versions of git did not allow this and asked you to create a temporary branch using the -b option, but starting from version 1.5.0, the above command detaches your HEAD from the current branch and directly points at the commit named by the tag (v2.6.18 in the example above).

You can use all git commands while in this state.
You can use git reset --hard $othercommit to further move around, for example.
You can make changes and create a new commit on top of a detached HEAD.
You can even create a merge by using git merge $othercommit.

The state you are in while your HEAD is detached is not recorded by any branch (which is natural --- you are not on any branch).
What this means is that you can discard your temporary commits and merges by switching back to an existing branch (e.g. git checkout master), and a later git prune or git gc would garbage-collect them.
If you did this by mistake, you can ask the reflog for HEAD where you were, e.g.

$ git log -g -2 HEAD

---

While git push says "everything up-to-date", you still can technically push a detached HEAD, as noted in the comments by Jonathan Benn

 git push origin HEAD:main

You have to specify the destination branch, since the source is not a branch, and does not have an upstream target branch.

Plott

It's not entirely clear to me how I got into this state (doing some mucking with git-svn at the moment), but this was enough to get me back to the right place. Thanks. – Reservation

I am in a detached head state, merged my changes, committed my changes and now I want to push this to Master and can't - tells me "everything up to date". But I am following the instructions provided my Gitlab: Step 1: git fetch origin git checkout -b "nodeAPI" "origin/nodeAPI" Step 2. Review the changes locally Step 3. Merge and fix conflicts git fetch origin git checkout "origin/master" git merge --no-ff "nodeAPI" Step 4. Push the result of the merge to GitLab git push origin "master" I'm good until the last step. But now I'm just confused how to move forward. – Restaurant

@Restaurant You need to be in a branch in order to push. As long as you are in a detached HEAD mode, that would not work. Reset your branch to where you are: git branch -f myBranch HEAD, then checkout said branch, and push it. In your case, myBranch might be master if you were in the process of merging nodeAPI. – Plott

Please beware of losing every local changes after running this command!! Consider doing some git stash & code backup before doing anything like this. – Fiveandten

@Fiveandten Good point: I have edited the answer to make that warning visible. – Plott

It's still possible to push to origin when your local Git is in a detached HEAD state: git push origin HEAD:master – Stannary

@JonathanBenn Good point. I have edited the answer to include your comment for more visibility. – Plott

Answer 2

Err.. If you are a git noob are you sure you have git commit before git push? I made this mistake the first time!

Ovoid

It was git commit -a -m "your message goes here" in my case – Anestassia

I LOVE ( sarcasm) every time that I am wanting to add a new project to a github I sometimes forget and the error message leads me to think I did something really wrong - then of course DUH! commit Only happens to me when I am created new backup repositories and I forget – Sloth

@FoxMcCloud Commiting is an important step to be conscious of, I'm sure you'll learn to love it if you haven't already :) ~ git add -A, git diff --staged, scrolls through changes hmm looking very good, git commit -m 'bam!', git push – Dowry

In my case (silly) I was hit by the "Tell me who you are" after git commit. Git requires you to re-run git commit in that case. – Belamy

Answer 3

Maybe you're pushing a new local branch?

A new local branch must be pushed explicitly:

git push origin your-new-branch-name

Just one of those things about git... You clone a repo, make a branch, commit some changes, push... "Everything is up to date". I understand why it happens, but this workflow is extremely unfriendly to newcomers.

Auspex

Thanks! This fixed my issue "everything up-to-date" with a new branch I had – Shrewsbury

What the heck is meant by "your-new-branch-name"? Ps: You are soooo right about newcomers. – Do

@user1863152 that's the name of the new local branch you created. Sounds like you didn't do that, so check other answers here. – Auspex

Totally agree with "this workflow is extremely unfriendly to newcomers". I am struggling with this since 1 hour. I setup remote and local repo. Made changes to local REAME file and try to push it to remote and nothing changes in remote. – Twana

This doesn't quite work, because in a detached HEAD state you need to specify the local branch/reference to use. – Stannary

Answer 4

My issue was that my local branch had a different name than the remote branch. I was able to push by doing the following:

$ git push origin local-branch-name:remote-branch-name

(Credit to https://penandpants.com/2013/02/07/git-pushing-to-a-remote-branch-with-a-different-name/)

Tang

The specific command for this case would be: git push origin HEAD:master – Stannary

Answer 5

$ git push origin local_branch:remote_branch

Explanation

I had the same error & spent hours trying to figure it out. Finally I found it. What I didn't know is that pushing like this git push origin branch-x will try to search for branch-x locally then push to remote branch-x.

In my case, I had two remote urls. I did a checkout from branch-x to branch-y when trying to push from y locally to x remote I had the message everything is up to date which is normal cause I was pushing to x of the second remote.

Long story short to not fall in this kind of trap you need to specify the source ref and the target ref:

$ git push origin local_branch:remote_branch

Update:

If you have to run this command every time you push your branch, you maybe need to set the upstream between your local & remote branch with the following :

$ git push --set-upstream origin local_branch:remote_branch

Or

$ git push -u origin local_branch:remote_branch

Untidy

'git push upstream dev:master' This means it will push source from dev to master. Right? – Burford

This helped me, I had another local branch named as the remote branch, what caused confusion. – Arrears

Ok this is definitely working for me but I am having to do this every time I want to push something to the remote. How do I fix it once and for all? – Ratite

you maybe need to set the upstream between your local & remote branch with the following : $ git push --set-upstream origin local_branch:remote_branch – Untidy

Answer 6

Another situation that is important to be aware of: The sort of default state for git is that you are working in the "master" branch. And for a lot of situations, you'll just hang out in that as your main working branch (although some people get fancy and do other things).

Anyway, that's just one branch. So a situation I might get into is:

My active branch is actually NOT the master branch. ... But I habitually do the command: git push (and I had previously done git push origin master, so it's a shortcut for THAT).

So I'm habitually pushing the master branch to the shared repo ... which is probably a good clean thing, in my case ...

But I have forgotten that the changes I have been working on are not yet IN the master branch !!!

So therefore everytime I try git push, and I see "Everything up to date", I want to scream, but of course, it is not git's fault! It's mine.

So instead, I merge my branch into master, and then do push, and everything is happy again.

Conquest

Answer 7

I have faced same issue. As I didn't add changes to staging area. And I directly tried to push the code to remote repo using command :

git push origin master

And it shows the message Everything up-to-date.

to fix this this issue, try these steps

1. git add .
2. git commit -m "Bug Fixed"
3. git push -u origin master

Bise

Answer 8

See VonC's answer above - I needed an extra step:

$ git log -1
- note the SHA-1 of latest commit
$ git checkout master
- reset your branch head to your previously detached commit
$ git reset --hard <commit-id>

I did this, but when I then tried to git push remoterepo master, it said "error: failed to push some refs. To prevent you from losing history, non-fast-forward updates were rejected, Merge the remote changes (e.g. 'git pull') before pushing again."

So I did 'git pull remoterepo master', and it found a conflict. I did git reset --hard <commit-id> again, copied the conflicted files to a backup folder, did git pull remoterepo master again, copied the conflicted files back into my project, did git commit, then git push remoterepo master, and this time it worked.

Git stopped saying 'everything is up to date' - and it stopped complaining about 'fast forwards'.

Harvin

Answer 9

Another very simple yet noobish mistake of mine: I simply forgot to add a message -m modifier in my commit. So I wrote:

git commit 'My message'

Instead of correct:

git commit -m 'My message'

NOTE: It does NOT throw any errors! But you will not be able to push your commits and always get Everything up to date instead

Proportionate

I don't realize why I make a simple mistake like this and need stackoverflow to find how to solve it. just reminder for myself in future, make sure do "git status" to check if you have commit it or not. – Drusy

Answer 10

From your git status, you probably has a different situation from mine.

But anyway, here is what happened to me.. I encountered the following error:

fatal: The remote end hung up unexpectedly
Everything up-to-date

The more informative message here is that the remote hung up. Turned out it is due to exceeding the http post buffer size. The solution is to increase it with

git config http.postBuffer 524288000

Ankara

Answer 11

Super rare - but still: On Windows, it might be that packed-refs has a branch with one letter case (i.e dev/mybranch), while refs folder has another case (i.e Dev/mybranch) when core.ignorecase is set to true.

The solution is to manually delete the relevant row from packed-refs. Didn't find a cleaner solution.

Punke

That was an issue for me too. Ended up with renaming folders with incorrect case inside .git folder (logs/refs/heads, refs/heads). – Sihun

Answer 12

I have faced a similar situation; when I made the changes and tried to git push origin master, it was saying everything was up to date.

I had to git add the changed file and then git push origin master. It started working from then on.

Orvil

Wouldn't you have to git commit that added file before pushing? – Anagnorisis

Answer 13

I ran into this myself when I merged a branch on Github and continued to develop in it locally. My fix was a little different than the others that have been suggested.

First I branched a new local branch off my old local branch (that I couldn't push). Then I pushed the new local branch to the origin server (Github). I.e.

$ git checkout -b newlocalbranch oldlocalbranch
$ git push origin newlocalbranch

This got the changes to show up on Github, albeit in newlocalbranch rather than oldlocalbranch.

Mavismavra

Answer 14

I had this problem today and it didn't have anything to do with any of the other answers. Here's what I did and how I fixed it:

A repository of mine recently moved, but I had a local copy. I branched off of my local "master" branch and made some changes--and then I remembered that the repository had moved. I used git remote set-url origin https://<my_new_repository_url> to set the new URL but when I pushed it would just say "Everything up to date" instead of pushing my new branch to master.

I ended up solving it by rebasing onto origin/master and then pushing with explicit branch names, like this:

$ git rebase <my_branch> origin/master
$ git push origin <my_branch>

I hope this helps anyone who had my same problem!

Emulsion

Answer 15

In my case I had 2 remote repos.

git remote -v
originhttps https://asim_kt@...
originhttps https://asim_kt@...
origin  ssh:[email protected]:...
origin  ssh:[email protected]:...

Both repo was same. Just one was https other was ssh. So removing the unwanted one, (In my case ssh. since I used https because ssh wasn't working!) fixed the issue for me.

Redintegration

Answer 16

I had a situation where I was on a feature branch and my coworker created his own feature branch as well. I ran git fetch -a and then git push origin <coworkers_branch>. This kept telling me that everything was up to date.

I fixed it by checking out into <coworkers_branch> and then pulling from my feature branch, and then committing and pushing back to <coworkers_branch>.

I honestly hope this helps someone, because I spent much more time than I should have with this.

Minne

Answer 17

git branch -M <desired branch>

This did the trick for me.

Bestrew

Answer 18

Verify you haven't goofed your remote URL.

I just wanted to also mention that I ran into this after enabling Git as a CVS in a local Jenkins build configuration. It appears that Jenkins checked out the most recent commit of the branch I gave it and also reset my remote to correspond to the paths I gave it to the repo. Had to checkout my feature branch again and fix my origin remote url with 'git remote set-url'. Don't go pointing a build tool to your working directory or you'll have a bad time. My remote was set to a file path to my working directory, so it naturally reported everything up-to-date when I attempted to push changes with the same source and destination.

Eyecatching

Answer 19

Another possibility is that you named a directory in your .gitignore file that got excluded. So the new commits wouldn't be pushed. It happened to me that I named a directory to ignore "search", but that was also a directory in my source tree.

Hann

Answer 20

There is a quick way I found. Go to your .git folder, open the HEAD file and change whatever branch you were on back to master. E.g. ref: refs/heads/master

Salesclerk

Actually setting it to refs/heads/master broke my repository. But setting it to what I thought to be the HEAD commit gave the following message: Warning: you are leaving 1 commit behind, not connected to any of your branches. I was able to take the commit over into a new branch and merge it back to the master. – Pinnule

Answer 21

My mistake was different than everything so far mentioned. If you have no idea why you would have a detached head, then you probably don't. I was working on autopilot with git commit and git push, and hadn't read the output from git commit. Turns out, it was an error message because I forgot -am.

[colin] ~/github/rentap.js [master] M % git commit 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'
error: pathspec 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' did not match any file(s) known to git.
[colin] ~/github/rentap.js [master] M % git push
Enter passphrase for key '/home/colin/.ssh/id_ecdsa': 
Everything up-to-date

Fixed it by putting -am where I usually do:

[colin] ~/github/rentap.js [master] M % git commit -am 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'

Megohm

Answer 22

I had the same issue. In my case it was caused by having to names for the same remote. It created the standard 'origin', but I've been using 'github' as my remote for a long time, so that was there too. As soon as I removed the 'origin' remote, the error went away.

Anorthic

Answer 23

here, my solution is different from the above. i haven't figured out how this problem happen, but i fixed it. a little unexpectedly.

now comes way:

$ git push origin  use_local_cache_v1
Everything up-to-date
$ git status
On branch test
Your branch is ahead of 'origin/use_local_cache_v1' by 4 commits.
  (use "git push" to publish your local commits)
  ......
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:use_local_cache_v1

To push to the branch of the same name on the remote, use

    git push origin test
    
$ git push origin HEAD:use_local_cache_v1    
Total 0 (delta 0), reused 0 (delta 0)
remote:

the command that works for me is

$git push origin HEAD:use_local_cache

（hope you guys get out of this trouble as soon as possible)

Gildea

push uses local_name:remote_name, so if you're on branch testyou can use git push origin test: use_local_cache_v1 – Brigadier

Answer 24

I had multiple remotes. All but one pushed correctly, so I knew I didn't have a detached HEAD or commit issues.

Instead, I had accidentally given two remotes the same URL. The remote with the duplicated URL failed because I was pushing to a URL that had already been pushed to!

Using git remote -v showed my list of remotes and their URLs, where I realized the issue.

Resetting the failing remote to its correct URL fixed the issue:
git remote set-url <remote-name> <correct-url>

Hertahertberg

Answer 25

Another rather infuriating situation to be aware of, when you've checked everything else and it still persists, you may suffer from branch.autoSetupMerge=always. From the docs:

always — automatic setup is done when the starting point is either a local branch or remote-tracking branch;

With this setting, checking out a new local branch based on main will mark your upstream as your starting point (in my case, main). So every time I tried to push, I got Everything up to date.

The fix: git config --global branch.autoSetupMerge simple. According to the docs,

simple — automatic setup is done only when the starting point is a remote-tracking branch and the new branch has the same name as the remote branch. This option defaults to true.

With this and the rest of my config, and fixing the remote tracking on affected branches, I can resume pushing new local branches to my remote.

Lecky

Answer 26

Another possibility is that you have commits that don't affect the directory you're pushing. So in my case I had a structure like

- .git
- README.md
- client/
 - package.json
 - example.js
- api/
 - requirements.txt
 - example.py

And I made a commit to master modifying README.md, then ran git subtree push --prefix client heroku-client master and got the message Everything up-to-date

Stony

Answer 27

I was working with Jupyter-Notebook when I encountered this deceptive error.

I wasn't able to resolve through the solutions provided above as I neither had a detached head nor did I have different names for my local and remote repo.

But what I did have was my file sizes were slightly greater than 1MB and the largest was almost ~2MB.

I reduced the file size of each of the file using How can I reduce the file size of my iPython notebook? technique.

It helped reduce my file size by clearing the outputs. I was able to push the code, henceforth as it brought my file size in KBs.

Klutz

Answer 28

We need to add the files and commit the already changed/added files execute below commands

git add . or git add nameoffile #it will add the existing files in the project

git commit -m "first commit" #commiting all the files in the project

git push origin master

Applecart

Answer 29

In my case, the cause of the trouble was that I was performing the git push/pull commands from a symlink folder in git bash! I was in a symlink folder inside a git project pointing to another git project, and the git pull/push commands were answering Everything up-to-date. When I moved (cd) to the actual folder's path (not through the symlink), git push/pull commands worked.

Buckwheat

Answer 30

For another potentially rare case, but worth mention - when you have pre-commit hooks configured in your local environment (scanning code for errors, e.g. for Python safety, flake8, black, isort, bandit etc...), if one of them fails, your commit also failed. This should be obvious in the console, but since the errors from the hooks can flood the console, you may not be aware you commit won't work until the pre-commit hooks are configured to ignore the issues or the issues are addressed.

Marozik

Answer 31

Silly error/reminder - formated my pc, reinstalled vscode and forgot to use enable autosave :).

Hopefully, you can realize faster and save yourself 10 min of debugging !

Dulcimer

Answer 32

I've faced this issue Everything up-to-date today without any error. I searched little bit and didn't get appropriate solution according to my problem so I've made git init to git commit process twice and here's the steps...

The problem while wanted to push

🅟 🅑 🅙  ₹ chhavi-ghar ₿ git push origin main                                                                   
Everything up-to-date
🅟 🅑 🅙  ₹ chhavi-ghar ₿ git push --force origin main                                                           
Everything up-to-date

I've used git pull and git push again but didn't work

🅟 🅑 🅙  ₹ chhavi-ghar ₿ git pull --rebase                                                                      
You are not currently on a branch.
Please specify which branch you want to rebase against.
See git-pull(1) for details.
git pull <remote> <branch>

🅟 🅑 🅙  ₹ chhavi-ghar ₿ git push origin main                                                                   
Everything up-to-date
🅟 🅑 🅙  ₹ chhavi-ghar ₿ git push --force origin main                                                           
Everything up-to-date

So finally I tried git init again and commit with different message and the following messages appear and follow these...

🅟 🅑 🅙  ₹ chhavi-ghar ₿ git init                                                                               
Reinitialized existing Git repository in /Users/xxxxxxxxx/Visual_Studio/chhavi-ghar/.git/
🅟 🅑 🅙  ₹ chhavi-ghar ₿ git add .                                                                              
🅟 🅑 🅙  ₹ chhavi-ghar ₿ git commit -m 'Updated Bookings'                                                       
interactive rebase in progress; onto <ongoing progress commit id>
Last commands done (2 commands done):
   pick <2nd last commit id> Updated
   pick <last commit id> Added Footer and Updated
No commands remaining.
You are currently editing a commit while rebasing branch 'main' on '<on progress commit id>'.
  (use "git commit --amend" to amend the current commit)
  (use "git rebase --continue" once you are satisfied with your changes)

nothing to commit, working tree clean
🅟 🅑 🅙  ₹ chhavi-ghar ₿ git rebase --continue                                                                  
Successfully rebased and updated refs/heads/main.
🅟 🅑 🅙  ₹ chhavi-ghar ₿ git push --force origin main                                                           
Enumerating objects: 143, done.
Counting objects: 100% (143/143), done.
Delta compression using up to 8 threads
Compressing objects: 100% (93/93), done.
Writing objects: 100% (96/96), 1.31 MiB | 8.84 MiB/s, done.
Total 96 (delta 47), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (47/47), completed with 39 local objects.
To https://github.com/xxx-xxx/Chhavi-Ghar.git
 + xxxxxxx...xxxxxxx main -> main (forced update) 

And here I chose --continue because I wanted my first ongoing commit not second temporary one named Updated Bookings. git rebase --continue will help to continue with the changes that you've made. And then try git push if it not work then git push --f origin main (recommended). In my case git push didn't work so I tried with force. And this push my previous commit which was creating problem named Updated Search Bar and Booking Section. Hope it'll help.

Soothe

git did mention You are not currently on a branch. with the first rebase - i tend to always start with a git status to remind myself what branch I'm on (as that tends to change frequently and isn't always what I expect it to be) – Brigadier