From: David Kastrup Date: Sat, 11 Aug 2007 10:32:18 GMT Subject: Re: [fixed PATCH] git-filter-branch.sh: Fix broken setting of GIT_DIR Message-ID: <85r6mawedp.fsf@lola.goethe.zz> In-Reply-To: <7vk5s2mllf.fsf@assigned-by-dhcp.cox.net> Junio C Hamano writes: > David Kastrup writes: > >> If filter-branch is entered with an unset GIT_DIR, things are rather >> fragile. The GIT_DIR variable setting then points to something like >> $(pwd)/../.. which is neither guaranteed to be a git directory > > I think this comment refers to this part, ... > >> -case "$GIT_DIR" in >> -/*) >> - ;; >> -*) >> - GIT_DIR="$(pwd)/../../$GIT_DIR" >> - ;; >> -esac > > ... however, at the beginning of the script, it dot-includes > git-sh-setup, which sets (but not export) GIT_DIR for the rest > of the script to use (see the last if..then..else). Ah, ok. In that case my patch is overengineered. However, one could replace the whole case with GITDIR=$(cd ../..;cd $GIT_DIR;pwd) This would work with Windows absolute paths, too. > If you got an unset GIT_DIR when you reached that case statement > you are removing here, I suspect that there is something else > going on, but I do not see what it is... > > Puzzled... The problem I saw was that "$(pwd)/../../$GIT_DIR" does no longer exist by the time the end of the script it reached, because what was "$(pwd)" has already been removed. So it is less onerous than I thought, but still a nuisance when the script ends. Anyway, if $GIT_DIR is a relative path, things would go wrong in some lines earlier, where the path is already being changed. If git-sh-setup sets GIT_DIR, perhaps it would be sanest if it also made it absolute? Otherwise any script that does "cd" will lose track of GIT_DIR, right? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum