git-checkout changes the index but not the checked out files?

I am a bit confused by git-checkout behaviour in the following scenario.

$ git version git version 1.5.1.gf8ce1

$ git-branch
  mdl17-polhn
* mdl18-local
  mdl18-topnz

$ git-status <shows a clean status>

# checkout an upstream branch to test that it has a bug $ git-checkout origin/MOODLE_18_STABLE $ git-status <shows a clean status>

# switch back to our local branch to test that the bug is gone $ git-checkout mdl18-local $ git-status <shows a very dirty status - the index has changed but the files weren't updated to the contents of mdl18-local> $ git-reset --hard # this fixes things back to normal

Is the bug in git-checkout or in my understanding? ;-) Perhaps I am modelling my use of git-checkout on how I used cg-switch and that's wrong. But reading the man page, it says:

When <paths> are not given, this command switches branches by updating the index and working tree to reflect the specified branch, <branch>, and updating HEAD to be <branch>

cheers,

martin

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

Shouldn't happen.  Details?

On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:

Hmnmm. Not sure really what to look for ;-)

If I try it on my git checkout (checkout origin/pu and then checkout master) nothing strange happens. But if I do it on my project, (fetchable from http://git.catalyst.net.nz/moodle-r2.git ) between a "local" mdl18-local and origin/MOODLE_18_STABLE, it all goes weird.

Just re-ran the process with bash -x, and it switches to a detached head when going to origin/MOODLE_18_STABLE (as expected). And when switching back, it all looks _almost_ reasonable except that there's a call to git-read-tree with -m and 2 sha1s. It is trying to merge mdl18-local and mdl18-topnz apparently.

In fact:

 - I am on mdl18-local
 - git-status is clean
 - git checkout mdl18-local reports "Already on branch "mdl18-local"
but it does a merge anyway

The problem seems to be that the SHA1 returned here is bogus:

   $ git-rev-parse --verify 'mdl18-local^0'
   warning: refname 'mdl18-local' is ambiguous.
   a26c09be05a08e5f911ef84b5f8010ba155ea77d

If I disambiguate it one way or the other, I get correct results

   $ git-rev-parse --verify 'refs/heads/mdl18-local^0'
   634dcf72a31d0c75a98c1d69dd4763def7bcf2d5
   $ git-rev-parse --verify 'remotes/origin/mdl18-local^0'
   6e6ae22a2960d3ac321acd1cdfa09f23068f33b4

but the ambiguous "git-rev-parse --verify 'mdl18-local^0'" returns the SHA1 for a head called 'mdl18-topnz' that I am not asking for. Why?

cheers,

m

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

Maybe you have a branch that is exactly the same name as a tag?

On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:

Nope - none of the tags look _anything_ like mdl18-local. See http://git.catalyst.net.nz/gitweb?p=moodle-r2.git;a=tags

I think mdl18-topnz was the first local branch I created in this checkout.

Hmmmm. There was a .git/mdl18-local file that had the bogus SHA1 in it: a26c09be05a08e5f911ef84b5f8010ba155ea77d . I don't know how it got there and how it had the wrong sha1 in it. Removing it has fixed it.

The _really_ strange bit is that it was attempting to merge 2 heads of the same name. It'd probably be something to block...

cheers,

martin

On Mon, 23 Apr 2007, Martin Langhoff wrote:

No, "git-read-tree -m A B" is not a "merge" in the sense you're thinking, it's a "fast-forward merge", ie just a "move from A to B"

So read-tree has three "merges": a one-way merge (which just merges with the old index _stat_ contents but otherwise just reads in the new tree), a two-way merge (a "move from A to B") that checks that all paths that are different in the two trees match the index in the old one, and the "real" merge, aka the three-way thing (and even that is actially "four-way", since it also checks the index for matchingness)

So when we move from one head to another, we do that two-way thing. And if A and B are the same, doesn't really do anything, but there's also no point to try to avoid doing it.

		Linus

On 4/24/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

...

Yup - except that the logic in git-commit wasn't expecting this at all, so it never said "fast-forwarding" and most importantly, it changed the index, and the checked out files, but didn't update the head it was aiming for.

There is definitely a bug when heads are ambiguous. Will try and find some time to fix it up in the coming days but I'm quite cornered with work here so if anyone wants to have a look at it...

cheers,

martin

Hallo,

Martin Langhoff wrote:

I already saw this, too.  In my case it was the result from making 

	git update-ref $branch ...

and I forgot to prefix $branch with refs/heads.

Best regards Uwe