David Kastrup <dak@xxxxxxx> writes:
> David Kastrup <dak@xxxxxxx> writes:
>
>> Anyway, if $GIT_DIR is a relative path, things would go wrong in some
>> lines earlier,
>
> and if GIT_DIR were used or exported which it isn't, so we are lucky...
>
>> 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?
>
> Actually, wouldn't by far the most straightforward thing be if
> git-rev-parse --git-dir always returned an absolute path (even when
> being passed a relative path in GIT_DIR)?
>
> No need for postprocessing, no need to keep track of changed
> directories.
To illustrate the potential for trouble:
git-commit.sh
has the lines
647:
cd_to_toplevel
git rerere
if test "$ret" = 0
then
if test -x "$GIT_DIR"/hooks/post-commit
then
"$GIT_DIR"/hooks/post-commit
fi
Obviously, this won't work if GIT_DIR has a relative path and the
command has not been started from the top level already.
In a similar vein, git-checkout.sh has
263:
GIT_DIR="$GIT_DIR" git symbolic-ref -m "checkout: moving from $old_branch_name to $branch" HEAD "refs/heads/$branch"
while we have previously cd_to_toplevel in line 154.
And so on. Rather than fixing all those scripts, it would seem safer
to let git-rev-parse --git-dir (I don't understand the code in
builtin-rev-parse, by the way: why does it look at "prefix"?), or at
the very least git-sh-setup.sh return an absolute path.
--
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
