Re: [PATCH v2 1/1] pathspec: warn for a no-glob entry that contains `**`

From: Stavros Ntentos <stdedos@gmail.com>
Date: Mar 26, 2021, 15:43 UTC
Message-ID: <20210326154350.17524-1-133706+stdedos@users.noreply.github.com>
In-Reply-To: <YF1tjaATILcSNuMa@coredump.intra.peff.net>

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.

Show 9 quoted lines

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