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

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

[Martin Langhoff]

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

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

[Junio C Hamano]

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

> # 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>

Shouldn't happen.  Details?

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

[Martin Langhoff]

On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:
> Shouldn't happen.  Details?

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

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

[Junio C Hamano]

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

> 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?

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

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

[Martin Langhoff]

On 4/23/07, Junio C Hamano <junkio@cox.net> wrote:
> > 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?
>
> Maybe you have a branch that is exactly the same name as a tag?

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

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

[Linus Torvalds]

On Mon, 23 Apr 2007, Martin Langhoff wrote:
> 
> The _really_ strange bit is that it was attempting to merge 2 heads of
> the same name. It'd probably be something to block...

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

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

[Uwe Kleine-König]

Hallo,

Martin Langhoff wrote:
> 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. 
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

-- 
Uwe Kleine-König

http://www.google.com/search?q=e+%5E+%28i+pi%29

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

[Martin Langhoff]

On 4/24/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, 23 Apr 2007, Martin Langhoff wrote:
> > The _really_ strange bit is that it was attempting to merge 2 heads of
> > the same name. It'd probably be something to block...
>
> 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 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.

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