Git wrongly states that I was ahead of the start / master by 1 commit
[edit: added command outputs on demand and refactored for clarity] I have two clones of a specific repo.
git log
commit e06424b5...
...
commit 557a0eb8...
shows the same in both cases, with the same hash at the top.
git remote show origin
the same in both
git branch
* master
still the same in both
Now some differences.
From a "good" clone:
git log origin/master..
commit e06424b5...
git show-ref HEAD
e06424b5... refs/remotes/origin/HEAD
# On branch master
nothing to commit (working directory clean)
Of the "bad" clones:
git log origin/master..
commit 557a0eb8...
git show-ref HEAD
557a0eb8... refs/remotes/origin/HEAD
git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
This is different [correction: I reported earlier that this result was the same). show-ref seems to indicate that this check is one commit, and the status says it is ahead. But git reset --hard e06424b5
it doesn't change anything.
When I ask the "bad" clone what it thinks, I have to press:
git diff --stat origin/master
it shows the files that were part of the e06424b5 commit, but actually the only reason this check even has these files is because I pulled them out.
Does anyone know how to make a check to realize that he has nothing to push?
[edit: here are some additional commands and their outputs from the "bad" clone ...]
git log --graph --decorate --oneline
* e06424b (HEAD, master)
* 557a0eb (origin/master, origin/HEAD)
git rev-parse origin/master
557a0eb
git rev-parse HEAD
557a0eb (the previous hash)
e06424b (the correct, most recent hash)
source to share
Based on your comments, it seems to me that you are indeed working in "head off" mode.
The problem is that your initial entry implies that the branch is pointing to a specific location, which you don't want (this would be much clearer if you actually posted whatever output from the git commands you run), in which case git reset is - -hard is what you expect to do to fix this.
But it actually seems like HEAD is just indicating that you expect it to be not, git checkout is the command you use to fix that HEAD points to. I am guessing that there might be something that is blocking the validation, so I added --force.
WARNING: Using git checkout with the -force option can kill any uncommitted changes or something like that.
git checkout --force master
Assuming you have a master branch, this is the one you want to checkout, and that it actually tracks the origin / master, this should get you out of the pickle you find yourself in.
source to share