git checkout branch puzzle

> I have been using msysgit (curently 1.7.0.2.msysgit.0) for about 18 months 
> and thought that I had managed to understand most things. However, the 
> following sequence has me baffled:
> 
> a) on branch 'master', git status shows that the working directory is clean
> 
> b) git checkout HEAD^ gives the usual moan about moving to a head which 
> isn't a local branch
> 
> c) git checkout master followed by git status gives "changed but not 
> updated" and a list of "modified" files

> On Sat, May 01, 2010 at 05:55:47PM +0000, Chris.Cheney wrote:
> 
>> I have been using msysgit (curently 1.7.0.2.msysgit.0) for about 18
>> months and thought that I had managed to understand most things.
>> However, the following sequence has me baffled:
>> 
>> a) on branch 'master', git status shows that the working directory is
>> clean 
>> 
>> b) git checkout HEAD^ gives the usual moan about moving to a head
>> which isn't a local branch
>> 
>> c) git checkout master followed by git status gives "changed but not 
>> updated" and a list of "modified" files
> 
> Part (c) shouldn't show anything in "git status". I wonder if it is a
> line-ending conversion issue, since you are using msysgit, and since
> that is the usual culprit for files mysteriously looking changed.
> Might you have recently changed the settings of core.autocrlf?
> 
> -Peff
> 

> Jeff King <peff@peff.net> wrote in
> news:20100502045901.GD14776@coredump.intra.peff.net: 
> 
>> On Sat, May 01, 2010 at 05:55:47PM +0000, Chris.Cheney wrote:
>> 
>>> I have been using msysgit (curently 1.7.0.2.msysgit.0) for about 18
>>> months and thought that I had managed to understand most things.
>>> However, the following sequence has me baffled:
>>> 
>>> a) on branch 'master', git status shows that the working directory
>>> is clean 
>>> 
>>> b) git checkout HEAD^ gives the usual moan about moving to a head
>>> which isn't a local branch
>>> 
>>> c) git checkout master followed by git status gives "changed but not
>>> updated" and a list of "modified" files
>> 
>> Part (c) shouldn't show anything in "git status". I wonder if it is a
>> line-ending conversion issue, since you are using msysgit, and since
>> that is the usual culprit for files mysteriously looking changed.
>> Might you have recently changed the settings of core.autocrlf?
>> 
>> -Peff
>> 
> 
> Thanks for the reply and confirming what I believed about (c). 
> 
> It is possible that what you suggest might be involved - it's a
> 2-developer situation, each using msysgit with their own local
> repository and a remote master (bare) repository. I'll compare the
> other's config file against mine.

> > Thanks for the reply and confirming what I believed about (c). 
> > 
> > It is possible that what you suggest might be involved - it's a
> > 2-developer situation, each using msysgit with their own local
> > repository and a remote master (bare) repository. I'll compare the
> > other's config file against mine.
> 
> Neither of our config files contain autocrlf settings, but it's something 
> that I'll look further into. Neither of us had made recent config changes.

> On Sun, May 02, 2010 at 08:09:32PM +0000, Chris.Cheney wrote:
> 
>> Neither of our config files contain autocrlf settings, but it's
>> something that I'll look further into. Neither of us had made recent
>> config changes. 
> 
> I believe autocrlf is on by default for msysgit. But if there is
> nothing in your config, then probably nothing changed. If you can
> reproduce the situation, it might be worth narrowing down a simple
> test case and posting the exact commands and output.

> Jeff King <peff@peff.net> wrote in
> news:20100503064053.GA20002@coredump.intra.peff.net: 
> 
>> On Sun, May 02, 2010 at 08:09:32PM +0000, Chris.Cheney wrote:
>> 
>>> Neither of our config files contain autocrlf settings, but it's
>>> something that I'll look further into. Neither of us had made recent
>>> config changes. 
>> 
>> I believe autocrlf is on by default for msysgit. But if there is
>> nothing in your config, then probably nothing changed. If you can
>> reproduce the situation, it might be worth narrowing down a simple
>> test case and posting the exact commands and output.
> 
> Thanks. Indeed, after asking here, that was to be my next step - I
> need to restock up on round tuits :-)
> 
> FWIW My money is on a rm/git-rm or a mv/git-mv "user" error.