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