Jeff King <peff@xxxxxxxx> writes: >> Now, instead of "", we use a pathspec prefix of NULL. If no path >> arguments were provided, get_pathspec() will return NULL, and we won't >> try to verify the existence of any paths in the tree. > > Yeah, this looks like the right thing to do. The get_pathspec code > treats a NULL prefix specially as "no prefix", and I think that is what > we are trying to say here (i.e., we are interpreting pathspecs from the > root). Yes, that sounds sane. > ... However, prefix_pathspec does a lot of magic parsing; > it's unclear to me whether this is all in support of properly > adding the prefix, or if its side effects are important. These "magic" are for things like :(root)/path that will explicitly refuse the prefix when run from a subdirectory. In the longer term, get_pathspec() should be converted to directly deal with "struct pathspec", but we are not there yet. There are too many code left-over, even after Duy's last pathspec related topic, that still look at ->raw field of "struct pathspec" and they all need to be taught to work with the unified pathspec matching machinery. This is one of the lots of unfinished loose ends, which might be a good GSoC project but may be a bit too large for a student to bite and chew. -- 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