Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: David Kastrup <hidden>
Date: 2016-06-15 22:43:28

Junio C Hamano [off-list ref] writes:
David Kastrup [off-list ref] writes:
quoted
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, ...
quoted
-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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help