Re: [RFC 4/6] git-check-attr: Normalize paths

[Michael Haggerty <mhagger@alum.mit.edu>]

On 08/04/2011 07:05 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>>> I think passing down "prefix" (i.e. where your $(cwd) was relative to the
>>> root level of the working tree) and the user-supplied "pathspec" (which
>>> typically is relative to that original $(cwd)) is the canonical approach.
>>> The very original git worked only at the root level of the working tree,
>>> with paths specified relative to the root level of the tree, so many code
>>> do:
>>>
>>> 	- find out the root of the working tree;
>>>         - note where the $(cwd) was in "prefix";
>>>         - chdir to the root of the working tree;
>>> 	- prepend the "prefix" to user supplied pathspec;
>>>         - forget all the complexity and work on the whole tree.
>>>
>>> Then the "prefix" gets stripped away from the beginning of the paths when
>>> reporting.
>>>
>>> Your patch from a cursory look seems to follow that pattern, which is
>>> good.
>>
>> Thanks for the explanation.
>>
>> Yes, my code follows the pattern, except that in this case it is
>> unnecessary to chdir to the root of the working tree.
> 
> Just to make sure there is no misunderstanding. The chdir() should not be
> in the core part of the system that you may want to libify.
> 
> The above pattern was developed primarily so that older utility functions
> in the system that were written back when nobody ran git from anywhere
> other than the top level of the working tree can be easily adapted to main
> programs that can be launched from a subdirectory. The initial set-up part
> of the program is responsible for figuring out "prefix", turning relative
> paths given by the user into paths relative to the top of the working
> tree, and then chdir'ing to the top.
> 
> After all that happens, the library-ish parts of the system only have to
> deal with full paths relative to the root of the working tree. "prefix"
> comes into play when reporting the results (i.e. showing paths relative to
> user's $(cwd) in the output or in the error messages).

If I understand you correctly, the use of some API routines requires a
chdir by the caller (i.e., the surrounding application) *before* calling
into the routine.  This is certainly a bit cleaner than the library
chdiring itself, but it is still unusable in a multithreaded context.
Regardless of whether the library chdirs itself or whether it obligates
callers to chdir before calling into the library, the bottom line is
that it requires a change to global state to function correctly, and
that change can confuse other threads.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/