I think I have managed to address everyone's questions in this thread. Hopefully everything will be addressed by this, and the patch that will soon follow: > You may notice that I would call both of those latter two "globbing", > but only one of them is triggered by the ":(glob)" magic. :) And that's why I argued a DWIM was warranted here (https://lore.kernel.org/git/xmqqft1iquka.fsf@gitster.g/; it's more clear in Junio's quote, but you could of course read the original). I would want to be considered as an above-average git user, and I still was oblivious to the fact that `**` required a `:(glob)` from the command line. Especially since `.gitignore` files are treated differently (i.e. don't require `:(glob)`) I cannot / don't want to argue to "do it" or not, as I think my experience is not substantial enough to navigate such argument, and go from concept to materialization. That being said, if there was a cli.pathspec.wildmatch flag, I would've had it set to true in my global gitconfig. Ofc I could set `GIT_GLOB_PATHSPECS=1`, but I am not that happy to force it by setting it in a shell rc, instead of where it belongs. > I am not sure everything after the "the sky:" you wrote is what you > meant to write. Without being marked with a "glob" magic, a > wildcard character in a pattern matches even a slash, so these two > > git ls-files 'Documentation**v2.txt' > git ls-files 'Documentation*v2.txt' > > give the identical result and there is nothing about "surrounded by > slashes" involved in it. It seems you are right - in `fnmatch` mode, `:!*.gitignore` would've served me right (and avoided the whole thread). If you think that it's just my (i.e. few people's) lacking of understanding `fnmatch` glob, then we can drop this. However, given the disparity between `.gitignore` syntax and pathspec given from the command line (from my limited POV meaningless/confusing), and your (plural) arguments of backwards compatibility, I think we can draw the line at an advice been acceptable. Unless I see other points (like the warn vs advice), or pure C code-review points, I am getting the impression that this thread will not move forward. As I don't know how reviews usually happen here, and lacking some other medium of discussion, I would appreciate (at some point) an explicit go/no-go decision - to save everyone's time. Being unfamiliar to the project, and being who I am, I prefer explicit vs implicit points. Navigating an unknown process from top to bottom is pressure enough to me :-D > seems to tell me that the "zero-or-more directories" magic happens > only when /**/ form is used, not when two asterisks are placed next > to each other in a random context. Not exactly: ** needs to either start or end with a slash (or both) for its wildmatch behavior. I can try to make the code more explicit, but of course the code (and tests) will increase - and then maybe disproportionately to the otherwise intended-to-be small change (since DWIM is not wanted).
