Re: git checkout -f: What am I missing?

[Michael J Gruber <git@drmicha.warpmail.net>]

Soham Mehta venit, vidit, dixit 27.01.2010 22:40:
> Thanks Michael.
> 
> Is that a bug? If not, how do I understand it?
> 
> -Soham
> 
> 
> thus spake Michael J Gruber , On 1/15/2010 7:28 AM:
>> Soham Mehta venit, vidit, dixit 14.01.2010 22:16:
>>   
>>> Hi,
>>>
>>> I have a situation with git that I'm trying to understand:
>>>
>>> Description:
>>> 1) GIT_DIR is set to /path/to/repo/.git
>>> 2) Repository is /not /a bare repo, and all files are nicely checked-out 
>>> in /path/to/repo/
>>> 3) Somebody pushes to that repo using ssh (any branch, checked-out or not)
>>> 4) Default post-receive hook runs (it is the only one +x) which sends 
>>> out an email 
>>> (http://repo.or.cz/w/git.git/blob/HEAD:/contrib/hooks/post-receive-email)
>>> 5) After it is done sending the email, I put "git checkout -f", at the 
>>> end in the same file, in case someone pushes to a checked-out branch
>>>
>>> Problem:
>>> It runs "checkout -f" as if inside .git directory, instead of on the 
>>> parent. i.e. it gets all files from the parent and writes them inside 
>>> .git. Parent is left untouched.
>>>
>>> Some more info:
>>> 0) We don't have GIT_DIR set in the environment. The hook does a 
>>> rev-parse to find it.
>>> 1) echo of $GIT_DIR right before the checkout -f line gives a "." .
>>> 2) It works as expected if I do this:  cd /path/to/repo && git 
>>> --git-dir=/path/to/repo/.git/ checkout -f
>>>
>>> What I do know:
>>> 1) Pushing to a checked-out branch is not a git best-practice, and some 
>>> git behavior is undefined in that case. We already have plans to go away 
>>> from that.
>>> 2) Git tends to like full path names instead of relative ones
>>>
>>> Can someone help me understand this behavior?
>>>     
>>
>> Does the thread
>> http://permalink.gmane.org/gmane.comp.version-control.git/136267
>> help by any chance?
>> You've found the solution, "cd .. && unset GIT_DIR" does it.
>>
>> Michael
>>   

Because it messes up the reading order.

Why?

Please don't top-post.

Back to your question: The thread I pointed you to explains that git
sets "GIT_DIR=.", and given that the behaviour is exactly as expected.
It's not a bug. Changing it may break existing hooks.

One may argue for a change in behaviour in the next major release, but
not 1.7. any more.

Michael