Alexandr Miloslavskiy <alexandr.miloslavskiy@xxxxxxxxxxx> writes:
> Is that expected?
>
> Other commands seem to not like that:
>
> $ git checkout NonExistingFile
> error: pathspec 'NonExistingFile' did not match any file(s) known to git
It's sort of expected ;-)
"git $subcmd -- pathspec" is defined to perform $subcmd to the paths
that match the given pathspec. "git checkout -- pathspec" checks
out the contents out of the index for such paths and "git reset --
pathspec" resets the contents in the index to that of HEAD for such
paths.
Historically, we did not consider it is an error for users to
specify an empty set (i.e. a pathspec with an element that does not
match any path). Because it is easy to mistype "git checkout --
*.rv", let the shell pass "*.rv" literally (because in a project
where you meant to say "*.rb", it is very plausible that there is no
such path for the glob to match) to "git checkout" and nobody would
give you any indication of an error, we made it an error for "git
checkout" to be fed a pathspec element that does not match [*1*].
It is expected that other commands that may benefit from a similar
handholding mechanism against end-user typos have not learned to do
so, simply because nobody bothered to bring it up ;-).
[Footnote]
*1* This cuts both ways and it used to hurt a lot more back when it
was introduced.
When you have many tracked *.rb files and some throwaway *.rb files
that are not tracked,
git checkout -- \*.rb
may checkout only the ones that are tracked (i.e. known to git---in
this case, known to the index) without molesting the untracked ones.
But people being people, they can be lazy and say
git checkout -- *.rb
instead (notice the lack of quoting for the asterisk). This would
first let your shell expand it and match untracked ones, and then
feed the resulting paths as a pathspec to "git checkout", so one of
the pathspec elements may be the "untracked.rb" throw-away file.
With the "it is an error for a pathspec element not to match any"
rule, such a use will now error out.
The good thing is that people can learn, and after getting such an
error message, they learn to quote the asterisk from the shell when
they want to Git expand it. So it may not hurt that much these
days as it used to.
