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). -- 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