Re: [fixed PATCH] git-filter-branch.sh: Fix broken setting of GIT_DIR

[David Kastrup <dak@gnu.org>]

Junio C Hamano <gitster@pobox.com> writes:

> David Kastrup <dak@gnu.org> 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