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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html