Junio C Hamano <gitster@xxxxxxxxx> writes: > David Kastrup <dak@xxxxxxx> 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 - 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
