Re: [PATCH 3/3] Replace setenv(GIT_DIR_ENVIRONMENT, ...) with set_git_dir()

[Johannes Sixt <j.sixt@viscovery.net>]

Steffen Prohaska schrieb:
> On Nov 22, 2007, at 8:52 AM, Junio C Hamano wrote:
>> I suspect that if there are even earlier callers than these
>> early parts in the codepaths (handle_options, enter_repo, and
>> setup_git_directory_gently), maybe these earlier callers are
>> doing something wrong.  Logically, if you are somewhere very
>> early in the codepath that you can still change the value of
>> GIT_DIR, you shouldn't have assumed the unknown value of GIT_DIR
>> and cached locations relative to that directory, no?  What are
>> the problematic callers?  What values do they access and why?
> 
> 
> I thought about these questions, too.  But only very briefly.
> I did not analyze the code path that lead to calls of getenv().
> 
> I'm not sure if it's really necessary.  Calling set_git_dir()
> looks more sensible too me than the old code.  I believe using
> set_git_dir() is the safer choice, and should not do any harm.
> So I stopped analyzing too much, and instead proposed to use
> set_git_dir().

Junio's point is this: If we stumble over a dangling pointer that getenv() 
produced, then this has obviously happened before setenv(GIT_DIR), and 
caching that pointer is probably the wrong thing to do anyway (because it 
refers to the wrong GIT_DIR) and needs to be fixed.

So the task is to find those traps. Dmitry obviously stumbled over one case, 
but I haven't ever encountered any problems with the current code. But then 
this might be sheer luck. And I'm not a heavy user of export GIT_DIR=foo, 
either. Do *you* know a problematic case?

> Interesting, though, is to find out if we have other potentially
> dangerous calls to getenv() that are not removed by this patch.

Side note for other readers: This is a Windows specific problem for the 
moment because its getenv() does not behave well.

-- Hannes