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

[Stavros Ntentos <stdedos@gmail.com>]

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