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

David Kastrup [off-list ref] writes:

David Kastrup [off-list ref] writes:

quoted

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...

quoted

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