On Sat, 25 Jan 2020 at 01:00, Jeff King <peff@xxxxxxxx> wrote: > > > We _could_ also say "even though this could technically be a pathspec > > > because of its metacharacter, it looks vaguely enough like a > > > path-in-tree revision that we shouldn't guess". That I'm less > > > comfortable with, just because it makes the heuristics even more > > > magical. > > > > Not just it becomes more magical, I am afraid that the code to > > implement such a heuristics would be fragile and become a source of > > unnecessary bugs. Let's not go there. > > OK. It does mean that: > > git show HEAD:a* > > will still quietly produce no output instead of saying "hey, there is no > a* in HEAD". But I think given the lack of bug reports over the years > that this case (and the backslash one I'm fixing) are probably > relatively rare. The backslash one seems a lot more likely, just > because Windows folks may treat it like a path separator (I'm not sure > if that even works, considering its meaning in a glob, but certainly I > can imagine somebody doing so as an experiment and getting confused by > the result). I'm normally in a Unix environment but needed to address a potential issue in Windows, which indeed got me confused about the results. Upon experimenting in said Unix environment with what you outlined above on making revision and pathspec explicit, I figured that it becomes a little odd in the case where one would use a glob meta character in a filename (why anybody would want that except for academic reasons is beyond me), but it could still be a source of bugs in tooling interacting with git: Given a repository initialized with $ git init && echo a > a && echo '*' > '*' && git add a '*' && git commit -m "first" && git rm a '*' && git commit -m "second" there's a bit of a discrepancy when using git show to dump the contents per revision. In the beginning, everything is normal for HEAD^ but for HEAD, it's a requirement to use disambiguation to avoid believing that '*' was an empty file. At the same time, the disambiguation causes the error message change its nature, for obvious reasons: $ git show 'HEAD^:a' a $ git show 'HEAD^:a' -- a $ git show 'HEAD^:*' # presumably get_oid finds the object * $ git show 'HEAD^:*' -- * $ git show 'HEAD:a' fatal: Path 'a' does not exist in 'HEAD' $ git show 'HEAD:a' -- fatal: bad revision 'HEAD:a' $ git show 'HEAD:*' $ git show 'HEAD:*' -- fatal: bad revision 'HEAD:*' Indeed, it seems to be working as designed or at least explainably. I'll make sure to add '--' in my tool integration to deal with this corner case.
