Giuseppe Bilotta [off-list ref] writes:
I'm pretty confident fixing this on the submodules side is the more correct
approach, since otherwise even a simple
$ GIT_WORK_TREE=. git submodule update
on the command-line can fail.
True; while I didn't bother to check what the codepaths after these
unsetting do, I suspect you should also think about what effect it has to
have other GIT_* environment variables seep through to them (GIT_INDEX_FILE,
GIT_CONFIG and GIT_OBJECT_DIRECTORY come to mind). You would probably
want to have a single shell helper function to unset even if you end up
deciding that it is sufficient to clear GIT_DIR and GIT_WORK_TREE and
nothing else.
On Mon, Feb 22, 2010 at 11:43 PM, Junio C Hamano [off-list ref] wrote:
Giuseppe Bilotta [off-list ref] writes:
quoted
I'm pretty confident fixing this on the submodules side is the more correct
approach, since otherwise even a simple
$ GIT_WORK_TREE=. git submodule update
on the command-line can fail.
True; while I didn't bother to check what the codepaths after these
unsetting do, I suspect you should also think about what effect it has to
have other GIT_* environment variables seep through to them (GIT_INDEX_FILE,
GIT_CONFIG and GIT_OBJECT_DIRECTORY come to mind). You would probably
want to have a single shell helper function to unset even if you end up
deciding that it is sufficient to clear GIT_DIR and GIT_WORK_TREE and
nothing else.
Good point. All GIT_* env variables should be resent when descending
into a submodule. Is there a way to loop over them, or do I have to do
something horrible like env | grep ^GIT_ | cut -f1 -d= to get the
list?
--
Giuseppe "Oblomov" Bilotta