1

[edit: added command outputs as requested, and reorganized for clarity] I've got two clones of a particular repo checked out. 

git log
commit e06424b5...
...
commit 557a0eb8...

shows the same thing in both, with same hash at the top.

git remote show origin

same in both

git branch
* master

still same in both

Now some differences.

From the '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)

From the 'bad' clone:

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: earlier I reported that this output was the same]. show-ref seems to indicate that this checkout is one commit behind, while status says it is ahead. But git reset --hard e06424b5 changes nothing.

When I ask the 'bad' clone what it thinks needs to be pushed:

git diff --stat origin/master

it shows the files that were part of the e06424b5 commit, but in fact the only reason this checkout even has those files is because I pulled them.

Anyone know how to make the checkout realize that there's nothing for it 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)
Magnus
  • 10,736
  • 5
  • 44
  • 57
  • Your comments aren't very clear. Some actual responses from git would be much more helpful then the commands you are giving it... does 'git diff HEAD origin/master' give anything? – Arelius Jan 31 '12 at 22:11
  • yes, 'git diff HEAD origin/master' shows a large set of diffs, which makes sense because HEAD is pointing to the previous hash, not the latest – Magnus Jan 31 '12 at 22:17
  • What do you have HEAD set to? when you do 'git branch' what is shown as the current branch? – Arelius Jan 31 '12 at 22:27
  • Can you please show the output of `git rev-parse origin/master`, `git rev-parse HEAD` on both clones and `git ls-remote origin` from either clone? – CB Bailey Jan 31 '12 at 22:28
  • 'git branch' points to master – Magnus Jan 31 '12 at 22:36
  • on the problem clone: 'git rev-parse origin/master' shows 557a0eb856c... (which is the previous commit hash), and 'git rev-parse HEAD' shows both 557a0eb856c... (the previous hash) and e06424b5296... (the correct, most recent hash). On the 'good' clone: rev-parse shows e06424b5296... (the correct, most recent hash) for both origin/master and HEAD – Magnus Jan 31 '12 at 22:40
  • It looks like you just need to perform a `git fetch` in the first clone, then you can `git merge origin/master`. Or you could `git pull`. – CB Bailey Jan 31 '12 at 23:05
  • Yes indeed it looks that way, and yet neither of those fixes it. Both say everything is already up to date – Magnus Jan 31 '12 at 23:11
  • 1
    `git fetch` doesn't clear this message? I've worked through this issue before: http://stackoverflow.com/questions/7365415/pull-only-repos-git-status-saying-the-branch-is-ahead-of-origin-master-why/7365922#7365922 – Nic Jan 31 '12 at 23:21
  • It actually just seems like you haven't pushed your changes to the remote branch... – Arelius Jan 31 '12 at 23:39

3 Answers3

2

You might have pushed from one of the repos ( the one without the ahead of message). Just because you pushed from one repo, doesn't mean that the other repo will be seeing the same thing. You have to do a git fetch origin so the tracking branches are updated.

manojlds
  • 290,304
  • 63
  • 469
  • 417
1

Considering your comments, it seems to me that you are actually working in a 'detached head' mode.

The problem, is that your initial post implies that a branch is pointing to a specific place that you don't want it to (This would be much more clear if you actually posted any of the output of the git commands you had run) in which case git reset --hard is what you would expect to do to fix this.

But in fact it seems that HEAD is just pointing to somewhere you expect it to not be, git checkout is the command you use to fix where HEAD is pointing to. I'm assuming that there may be something blocking the checkout from working, which is why I've added --force.

WARNING: using git checkout with the --force parameter may kill any uncommitted changes you have, or things of the like.

git checkout --force master

Assuming you have a master branch, it's the one you want to checkout, and that it is in fact actually tracking origin/master, this should get you out of the pickle you have found yourself in.

Arelius
  • 1,216
  • 8
  • 15
0

see the output of

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

It will show you graphically where each reference is pointing. You can also investigate with

gitk master origin/master HEAD
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • I already know that HEAD is pointing to the wrong place, I just can't make git correct it... reset --hard doesnt seem to have any effect – Magnus Jan 31 '12 at 23:07
  • you use checkout to move HEAD, git reset changes the current branch. 'git checkout master' to move head to the master branch, or 'git checkout origin/master' to move to the master branch from the origin remote. also you can just do a 'git checkout – Arelius Jan 31 '12 at 23:30
  • if you `git status` it should show you "# not on any branch". This means you are headless - not on any branch. But if it says you are ahead of something, it means you are on a branch. – Adam Dymitruk Jan 31 '12 at 23:46