Duy Nguyen <pclouds@xxxxxxxxx> writes:
> On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse <apelisse@xxxxxxxxx> wrote:
>> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>>
>> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
>> <tfnico@xxxxxxxxx> wrote:
>>> This was discussed on the Git user list recently [1].
>>>
>>> #in a repo with no files
>>>> git add -A
>>> fatal: pathspec '.' did not match any files
>>>
>>> The same goes for git add . (and -u).
>>>
>>> Whereas I think some warning feedback is useful, we are curious
>>> whether this is an intentional change or not.
The logic to produce that error message is primarily to catch a typo
like:
$ git add Nakefile
when the user meant to say Makefile.
It could be argued that a "git add [<any option>] .", with an
explicit "." given by the end-user, that is run in an empty
directory may be an error worth reporting. Just like it is likely
for the user to have wanted to add some other file when he typed
Nakefile and it is not good to silently decide "ah, nothing matches
the pathspec, so not adding anything is the right thing to do" in
such a case, it is plausible that the user thought that he was in
some other directory he wanted to add its contents to the index when
he gave us the explicit ".", while he was in fact in a wrong
directory, and it is not good to silently decide "nothing there to
add so I won't do anything" without any indication of an error.
We should *not* error out "git add [<any option>]" without any
end-user pathspecs, especially with that error message, on the other
hand.
> I was not aware of this case when I made the change. It's caused by
> this change that removes pathspec.raw[i][0] check in builtin/add.c in
> 84b8b5d .
>
> - for (i = 0; pathspec.raw[i]; i++) {
> - if (!seen[i] && pathspec.raw[i][0]
> - && !file_exists(pathspec.raw[i])) {
> + for (i = 0; i < pathspec.nr; i++) {
> + const char *path = pathspec.items[i].match;
> + if (!seen[i] && !file_exists(path)) {
>
> Adding it back requires some thinking because "path" in the new code
> could be something magic.. and the new behavior makes sense, so I'm
> inclined to keep it as is, unless people have other opinions.
>
>>>
>>> [1] https://groups.google.com/d/topic/git-users/Qs4YSPhTsqE/discussion
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe git" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html