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

git rev-parse HEAD
557a0eb (the previous hash)
e06424b (the correct, most recent hash)



source to share

3 answers

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.



You may have pushed one of the repos (the one with no post). Just because you pushed off one repo doesn't mean that another repo will see the same thing. You must have git fetch origin

the tracking branches update.



see output

git log origin/master HEAD master --graph --decorate --oneline


It will show you graphically where each link is. You can also explore with

gitk master origin/master HEAD




All Articles