On 08/04/2011 07:05 PM, Junio C Hamano wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> 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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html