git add -A fails in empty repository since 1.8.5

git add -A fails in empty repository since 1.8.5

[Thomas Ferris Nicolaisen]

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.

[1] https://groups.google.com/d/topic/git-users/Qs4YSPhTsqE/discussion

Re: git add -A fails in empty repository since 1.8.5

[Antoine Pelisse]

FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).

On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
<tfnico@gmail.com> 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.
>
> [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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git add -A fails in empty repository since 1.8.5

[Duy Nguyen]

On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse <apelisse@gmail.com> wrote:
> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>
> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
> <tfnico@gmail.com> 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.

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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Duy

Re: git add -A fails in empty repository since 1.8.5

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse <apelisse@gmail.com> wrote:
>> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>>
>> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
>> <tfnico@gmail.com> 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@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git add -A fails in empty repository since 1.8.5

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

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

But what we have right now is really weird:

# setup repo with one empty dir:
$ rm -fr test
$ git init test
Initialized empty Git repository in /tmp/test/.git/
$ cd test
$ mkdir foo

$ git add .
fatal: pathspec '.' did not match any files

=> The one we're discussing.

$ git add foo

=> No error when an empty directory other than . is given.

$ cd foo
$ git add .

=> No error either for "git add ." when not at the root of the repo.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git add -A fails in empty repository since 1.8.5

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.
>
> But what we have right now is really weird:

I know.  That is why I said "It _could_ be argued".

Re: git add -A fails in empty repository since 1.8.5

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse <apelisse@gmail.com> wrote:
>> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>>
>> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
>> <tfnico@gmail.com> 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.
>
> 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)) {

Isn't that pathspec.raw[i][0] check merely an attempt to work around
the combination of

 (1) "the current directory" pathspec "." is sanitized down to an
     empty string by the pathspec code; and

 (2) even though file_exists() is willing to say "yes" to a non-file
     (namely, a directory), it is not prepared to take an empty
     string resulting from (1) to mean "the directory .".

> Adding it back requires some thinking because "path" in the new code
> could be something magic..

Ehh, why?  Shouldn't "something magic" that did _not_ match
(i.e. not in seen[]) diagnosed as such?

I am wondering why we even need !file_exists(path) check there in
the first place.  We run fill_directory() and then let
prune_directory() report which pathspec did not have any match via
the seen[] array.  We also match pathspec against the index to see
if there are pathspec that does not match anything.  So at that
point of the codeflow, we ought to be able to make sure that seen[]
is the _only_ thing we need to consult to see if there are any
pathspec elements that did not match.

Stepping back even further, I wonder if this "yes, I found a
matching entity and know this is not an end-user typo" bit actually
should be _in_ "struct pathspec".  Traditionally we implemented that
bit as a separate seen[] array parallel to "const char **pathspec"
array, but that was merely because we only had the list of strings.
Now we express a pathspec as a list of "struct pathspec" elements,
I think seen[] can and should become part of the pathspec.  Am I
missing something?


> 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@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git add -A fails in empty repository since 1.8.5

[Duy Nguyen]

On Thu, Dec 19, 2013 at 3:57 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse <apelisse@gmail.com> wrote:
>>> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>>>
>>> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
>>> <tfnico@gmail.com> 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.
>>
>> 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)) {
>
> Isn't that pathspec.raw[i][0] check merely an attempt to work around
> the combination of
>
>  (1) "the current directory" pathspec "." is sanitized down to an
>      empty string by the pathspec code; and
>
>  (2) even though file_exists() is willing to say "yes" to a non-file
>      (namely, a directory), it is not prepared to take an empty
>      string resulting from (1) to mean "the directory .".

Yeah, and it was added so intentionally in 07d7bed (add: don't
complain when adding empty project root - 2009-04-28). So this is a
regression.

>> Adding it back requires some thinking because "path" in the new code
>> could be something magic..
>
> Ehh, why?  Shouldn't "something magic" that did _not_ match
> (i.e. not in seen[]) diagnosed as such?
>
> I am wondering why we even need !file_exists(path) check there in
> the first place.  We run fill_directory() and then let
> prune_directory() report which pathspec did not have any match via
> the seen[] array.  We also match pathspec against the index to see
> if there are pathspec that does not match anything.  So at that
> point of the codeflow, we ought to be able to make sure that seen[]
> is the _only_ thing we need to consult to see if there are any
> pathspec elements that did not match.

See e96980e (builtin-add: simplify (and increase accuracy of) exclude
handling - 2007-06-12). It has something to do with directory check
originally, then we don't care about S_ISDIR() any more and turn it to
file_exists(). Maybe it's safe to remove it now. Need to check
fill_directory() again..

> Stepping back even further, I wonder if this "yes, I found a
> matching entity and know this is not an end-user typo" bit actually
> should be _in_ "struct pathspec".  Traditionally we implemented that
> bit as a separate seen[] array parallel to "const char **pathspec"
> array, but that was merely because we only had the list of strings.
> Now we express a pathspec as a list of "struct pathspec" elements,
> I think seen[] can and should become part of the pathspec.  Am I
> missing something?

Yes it probably better belongs to struct pathspec. Turning it into 1
flag would simplify seen[] memory management too.

>
>
>> 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@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Duy

[PATCH] add: don't complain when adding empty project root

[Nguyễn Thái Ngọc Duy]

This behavior was added in 07d7bed (add: don't complain when adding
empty project root - 2009-04-28) then broken by 84b8b5d (remove
match_pathspec() in favor of match_pathspec_depth() -
2013-07-14). Reinstate it.

Noticed-by: Thomas Ferris Nicolaisen <tfnico@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/add.c  | 2 +-
 t/t3700-add.sh | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/builtin/add.c b/builtin/add.c
index 226f758..fbd3f3a 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -544,7 +544,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 
 		for (i = 0; i < pathspec.nr; i++) {
 			const char *path = pathspec.items[i].match;
-			if (!seen[i] &&
+			if (!seen[i] && pathspec.items[i].match[0] &&
 			    ((pathspec.items[i].magic &
 			      (PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
 			     !file_exists(path))) {
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index aab86e8..1535d8f 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -307,4 +307,8 @@ test_expect_success 'git add --dry-run --ignore-missing of non-existing file out
 	test_i18ncmp expect.err actual.err
 '
 
+test_expect_success 'git add -A on empty repo does not error out' '
+	git init empty && ( cd empty && git add -A . )
+'
+
 test_done
-- 
1.8.5.2.240.g8478abd

Re: [PATCH] add: don't complain when adding empty project root

[Torsten Bögershausen]

On 2013-12-23 10.02, Nguyễn Thái Ngọc Duy wrote:
> This behavior was added in 07d7bed (add: don't complain when adding
> empty project root - 2009-04-28) then broken by 84b8b5d (remove
> match_pathspec() in favor of match_pathspec_depth() -
> 2013-07-14). Reinstate it.
> 
> Noticed-by: Thomas Ferris Nicolaisen <tfnico@gmail.com>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  builtin/add.c  | 2 +-
>  t/t3700-add.sh | 4 ++++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/builtin/add.c b/builtin/add.c
> index 226f758..fbd3f3a 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -544,7 +544,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>  
>  		for (i = 0; i < pathspec.nr; i++) {
>  			const char *path = pathspec.items[i].match;
> -			if (!seen[i] &&
> +			if (!seen[i] && pathspec.items[i].match[0] &&
>  			    ((pathspec.items[i].magic &
>  			      (PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
>  			     !file_exists(path))) {
> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> index aab86e8..1535d8f 100755
> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -307,4 +307,8 @@ test_expect_success 'git add --dry-run --ignore-missing of non-existing file out
>  	test_i18ncmp expect.err actual.err
>  '
>  
> +test_expect_success 'git add -A on empty repo does not error out' '
> +	git init empty && ( cd empty && git add -A . )
> +'
> +
>  test_done
> 
I am (a little bit) confused.

This is what git does:
 rm -rf test && mkdir test && cd test && git init && touch A && mkdir D && cd D && touch B && git add . && git status
Initialized empty Git repository in /Users/tb/test/test/.git/
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   B

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        ../A
----------------
And the behaviour is in line with
https://www.kernel.org/pub/software/scm/git/docs/git-add.html

"." stands for the current directory somewhere in the worktree,
not only the "project root".
-----------------

Could it make sense to mention that replace
[PATCH] add: don't complain when adding empty project root
with
[PATCH] add: don't complain when adding empty directory.

(and similar in the commit message)
/Torsten

Re: [PATCH] add: don't complain when adding empty project root

[Duy Nguyen]

On Tue, Dec 24, 2013 at 12:48 AM, Torsten Bögershausen <tboegi@web.de> wrote:
>> +test_expect_success 'git add -A on empty repo does not error out' '
>> +     git init empty && ( cd empty && git add -A . )
>> +'
>> +
>>  test_done
>>
> I am (a little bit) confused.
>
> This is what git does:
>  rm -rf test && mkdir test && cd test && git init && touch A && mkdir D && cd D && touch B && git add . && git status
> Initialized empty Git repository in /Users/tb/test/test/.git/
> On branch master
>
> Initial commit
>
> Changes to be committed:
>   (use "git rm --cached <file>..." to unstage)
>
>         new file:   B
>
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
>
>         ../A
> ----------------
> And the behaviour is in line with
> https://www.kernel.org/pub/software/scm/git/docs/git-add.html
>
> "." stands for the current directory somewhere in the worktree,
> not only the "project root".

Yes, except in this case "." is project root because current dir is. I
could have done "git add -A" (without the dot) like reported, but that
will be deprecated soon. Another way to make it clear about project
root is use "git add -A :/". I'll send an update if it makes it
clearer.

> -----------------
>
> Could it make sense to mention that replace
> [PATCH] add: don't complain when adding empty project root
> with
> [PATCH] add: don't complain when adding empty directory.

We don't complain about adding an empty directory before or after this patch.

>
> (and similar in the commit message)
> /Torsten
>



-- 
Duy

Re: [PATCH] add: don't complain when adding empty project root

[Torsten Bögershausen]

On 2013-12-24 00.46, Duy Nguyen wrote:
>
[snip]
> We don't complain about adding an empty directory before or after this patch.
Ok, thanks for the explanation.

I think that
https://www.kernel.org/pub/software/scm/git/docs/git-add.html
could deserve an update.

My understanding is that <filepattern> is related to $GIT_DIR,
but "." is the current directory. 

I will be happy to write a patch,
(or to review one, whatever comes first)
/Torsten
 

Re: [PATCH] add: don't complain when adding empty project root

[Duy Nguyen]

On Wed, Dec 25, 2013 at 4:48 AM, Torsten Bögershausen <tboegi@web.de> wrote:
> On 2013-12-24 00.46, Duy Nguyen wrote:
>>
> [snip]
>> We don't complain about adding an empty directory before or after this patch.
> Ok, thanks for the explanation.
>
> I think that
> https://www.kernel.org/pub/software/scm/git/docs/git-add.html
> could deserve an update.
>
> My understanding is that <filepattern> is related to $GIT_DIR,
> but "." is the current directory.
>
> I will be happy to write a patch,
> (or to review one, whatever comes first)
> /Torsten

filepattern is related to current directory too (e.g. "*.sh" from "t"
won't cover git-rebase.sh, ":/*.sh" does). Yes a patch to update
git-add.txt to use the term "pathspec" instead of "filepattern" would
be nice. A pointer to pathspec glossary could help discover
case-insensitive matching, negative matching..
-- 
Duy

Re: [PATCH] add: don't complain when adding empty project root

[Torsten Bögershausen]

[]
> filepattern is related to current directory too (e.g. "*.sh" from "t"
> won't cover git-rebase.sh, ":/*.sh" does). Yes a patch to update
> git-add.txt to use the term "pathspec" instead of "filepattern" would
> be nice. A pointer to pathspec glossary could help discover
> case-insensitive matching, negative matching..


To somewhat end this thread: 
I haven't been able to find a patch that really improves the documentation,
because "Documentation/git-add.txt" has already been updated:

commit 30784198b766b19a639c199e4365f2a805fc08c6
Author: Junio C Hamano <gitster@pobox.com>
Date:   Thu Feb 14 15:51:43 2013 -0800

    Documentation/git-add: kill remaining <filepattern>
--------------------

And all changes are here:
http://git-htmldocs.googlecode.com/git/git-add.html

But, look at
https://www.kernel.org/pub/software/scm/git/docs/git-add.html

This page seems to need an update too, and I wonder why:
a) The makefile did'nt re-generate html even if it should have
b) That page is not owned or updated by the git.git maintainer
c) Any other reason?


Does anybody know how to trigger an update at kernel.org?

/Torsten

Re: [PATCH] add: don't complain when adding empty project root

[Junio C Hamano]

Torsten Bögershausen <tboegi@web.de> writes:

> But, look at
> https://www.kernel.org/pub/software/scm/git/docs/git-add.html
>
> This page seems to need an update too, and I wonder why:
> a) The makefile did'nt re-generate html even if it should have
> b) That page is not owned or updated by the git.git maintainer
> c) Any other reason?

Sorry, but if I understand correctly, k.org these days requires each
file to be GPG signed and uploaded individually (i.e. there is no
way as far as I can tell to say "here is a tarball, and I've even
signed it with my key to convince you that it is from me. Please
accept it and then unpack the contents there").  There is no way I'd
do that every time I update git-htmldocs repository for 500+ files.

Re: [PATCH] add: don't complain when adding empty project root

[Jonathan Nieder]

Hi,

Nguyễn Thái Ngọc Duy wrote:

> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>

Thanks.

[...]
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -544,7 +544,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>  
>  		for (i = 0; i < pathspec.nr; i++) {
>  			const char *path = pathspec.items[i].match;
> -			if (!seen[i] &&
> +			if (!seen[i] && pathspec.items[i].match[0] &&
>  			    ((pathspec.items[i].magic &
>  			      (PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
>  			     !file_exists(path))) {

Nit: in this loop there's already the synonym 'path' for item.match,
so perhaps

			if (!seen[i] && path[0] && ...)

would be clearer.

Should "git add --refresh ." get the same treatment?

> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -307,4 +307,8 @@ test_expect_success 'git add --dry-run --ignore-missing of non-existing file out
>  	test_i18ncmp expect.err actual.err
>  '
>  
> +test_expect_success 'git add -A on empty repo does not error out' '
> +	git init empty && ( cd empty && git add -A . )
> +'

Adding a test at the end like this means the tests come in chronological
order instead of logical order and simultaneous patches to the same
test script become more likely to conflict.

How about something like the following, for squashing in?

With or without the tweaks below,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

diff --git i/builtin/add.c w/builtin/add.c
index fbd3f3a..d7e3e44 100644
--- i/builtin/add.c
+++ w/builtin/add.c
@@ -544,7 +544,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 
 		for (i = 0; i < pathspec.nr; i++) {
 			const char *path = pathspec.items[i].match;
-			if (!seen[i] && pathspec.items[i].match[0] &&
+			if (!seen[i] && path[0] &&
 			    ((pathspec.items[i].magic &
 			      (PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
 			     !file_exists(path))) {
diff --git i/t/t3700-add.sh w/t/t3700-add.sh
index 1535d8f..fe274e2 100755
--- i/t/t3700-add.sh
+++ w/t/t3700-add.sh
@@ -272,6 +272,25 @@ test_expect_success '"add non-existent" should fail' '
 	! (git ls-files | grep "non-existent")
 '
 
+test_expect_success 'git add -A on empty repo does not error out' '
+	rm -fr empty &&
+	git init empty &&
+	(
+		cd empty &&
+		git add -A . &&
+		git add -A
+	)
+'
+
+test_expect_success '"git add ." in empty repo' '
+	rm -fr empty &&
+	git init empty &&
+	(
+		cd empty &&
+		git add .
+	)
+'
+
 test_expect_success 'git add --dry-run of existing changed file' "
 	echo new >>track-this &&
 	git add --dry-run track-this >actual 2>&1 &&
@@ -307,8 +326,4 @@ test_expect_success 'git add --dry-run --ignore-missing of non-existing file out
 	test_i18ncmp expect.err actual.err
 '
 
-test_expect_success 'git add -A on empty repo does not error out' '
-	git init empty && ( cd empty && git add -A . )
-'
-
 test_done

Re: [PATCH] add: don't complain when adding empty project root

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> How about something like the following, for squashing in?
>
> With or without the tweaks below,
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks, both.

Regarding "git add --refresh" (no other arguments), it would say
"Nothing specified, nothing added.", and that is unrelated to the
breakage reported and fixed in this thread, I think.  It is the same
message "git add" (no other arguments) gives, which I think is a
mistake.  "git add --refresh" is like "git add -u" in that the
affected paths are determined by the index, and running these
commands while your index is still empty can just be a silent no-op.

Re: [PATCH] add: don't complain when adding empty project root

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Regarding "git add --refresh" (no other arguments), it would say
> "Nothing specified, nothing added.", and that is unrelated to the
> breakage reported and fixed in this thread, I think.  It is the same
> message "git add" (no other arguments) gives, which I think is a
> mistake.  "git add --refresh" is like "git add -u" in that the
> affected paths are determined by the index, and running these
> commands while your index is still empty can just be a silent no-op.

Something like this...

 builtin/add.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/builtin/add.c b/builtin/add.c
index d7e3e44..84e8a3e 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -483,8 +483,10 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 		 (implicit_dot ? ADD_CACHE_IMPLICIT_DOT : 0);
 
 	if (require_pathspec && argc == 0) {
-		fprintf(stderr, _("Nothing specified, nothing added.\n"));
-		fprintf(stderr, _("Maybe you wanted to say 'git add .'?\n"));
+		if (!refresh_only) {
+			fprintf(stderr, _("Nothing specified, nothing added.\n"));
+			fprintf(stderr, _("Maybe you wanted to say 'git add .'?\n"));
+		}
 		return 0;
 	}