Repost: Inconsistent Behavior in 'git add' (git 2.52.0)?

Any response to this?

Should I submit it in a bug report even though it's probably not a bug?

Thanks, Jon

---

A while back (6 Sep 2025) I submitted a report about how running

     git add x bogus_file

where 'x' exists but 'bogus_file' doesn't results in 'x' not being added to the index. Peff was kind enough to explain that the presence of even 1 invalid file invalidates the whole 'git add' command, no matter how many valid files are included. OK, fine.

This morning I was experimenting with what happens if a file is specified on a 'git add' command line where the file exists but is in a .gitignore file. I was expecting the same behavior as when the file doesn't exist at all. Here's what happened:

% ls -l file1 jon -rw-r--r-- 1 jonf 15 Dec 30 15:36 file1 -rw-r--r-- 1 jonf 0 Jan 4 11:19 jon

% git check-ignore -v file1 .gitignore:2:file1 file1

So far, so good. Both file1 and jon exist, but file1 is in .gitignore. Just for yuks, I start with a clean repo.

% git init Initialized empty Git repository in /tmp/fish/.git/

The index is empty, as shown by % git ls-files --cached %

I then ran

% git add file1 jon git add file1 jon The following paths are ignored by one of your .gitignore files: file1

Again, this is exactly what I expected. But, running '% git ls-files --cached' shows

jon

This is *not* what I expected. I expected the 'git add' command to not add anything to the index, the same way it behaved when I tried to add a file that doesn't exist (see the beginning of this message). But, apparently specifying a missing file is considered a different kind of error than specifying an ignored file.

Once again, I'm wondering if this is expected behavior.

Cordially, Jon Forrest

Jon Forrest <nobozo@gmail.com> writes:

If the exclude mechanism does not allow others to go through when it kicks in, like "file1 is listed in .gitignore, so it should not be added unless it is forced", it would make it almost useless. Imagine running "git add ." instead of running "git add file1 jon" and seeing that nothing gets added?

It is plausible to teach "git add" to treat paths that are explicitly named on the command line (as opposed to the paths that are discovered due to recursion) differently, but that would be a new feature, not a bugfix, I would think.

Even then, I am not sure how useful it would be. Imagine running "git add *" instead of "git add ." or "git add file1 jon" and seeing that nothing gets added? Unlike "giving a '.' would let 'git add' discover 'file1' and 'jon' due to recursion", an asterisk on the command line that is not quoted is expanded by the shell command interpreter, and by the time 'git add' sees the parameters given to it, it cannot tell if 'file1' was explicitly typed or expanded via '*'. It would be mildly irritating if the addition is rejected.

So, I dunno.

Thanks for your response. This is indeed a very minor issue.

On 1/15/26 8:55 AM, Junio C Hamano wrote:

Agreed. I had been thinking of 'git add' as a kind of database transaction, where either everything happens, or nothing happens.

An excluded file isn't considered the same type of error as an invalid file, which is fine as long as a user is aware of this behavior. The fact that 'git add' warns about ignored files helps.

Again, this is a tiny, tiny issue.

Cordially, Jon Forrest