git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Jan 28, 2010, 10:27 UTC
Message-ID
<4B616681.4080700@drmicha.warpmail.net>
In-Reply-To
<4B60B2CF.10401@box.net>
Soham Mehta venit, vidit, dixit 27.01.2010 22:40:
Show 53 quoted lines
> 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
Previous: Michael J Gruber
Message 3 of 3 in “git checkout -f: What am I missing?”
  1. Soham MehtaJan 14, 2010
  2. Michael J GruberJan 15, 2010
  3. Michael J GruberJan 28, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.