On Fri, Sep 23, 2016 at 12:20 PM, Junio C Hamano <gits...@pobox.com> wrote: > There is an interesting observation around this code. Note that it > is just something to keep in mind, even though I think we are in no > position to solve this within the scope of this series, or in fact I > am not sure if there is anything to "fix". > > The expectation here is that the leading part of pathspec elements > contain path components above and outside the current working tree, > e.g. in a superproject with a submodule at "sub/", the end-user may > have said from the top of the superproject > > A saving grace is that "s*b/file" in this case is what the end-user > is giving us, not something we internally generated. So we can > simply blame the end user, saying "what --recurse-submodules does is > to (conceptually) flatten the indices of submodules into the index > of the superproject and show the entries that match your pathspec. > Because you gave us 's*b/file', which does match 's*b/oob/file', > that is what you get." > > ;-)
Yeah I've been thinking a bit about that as well. To me, it is incredibly silly to have a wildcard character in a filename (its unfortunate that its allowed). We can easily do as you suggest and simply blame the user and if they do have wildcard characters in their filenames they would just need to force the pathspec code to do checks literally (using the appropriate pathspec magic). This would just limit their ability to use actual wildcards in their pathspecs, ie they have to pick wildcards in their filenames or the ability to do wildmatching. -Brandon
