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.