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

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

[Jon Forrest]

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

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

[Junio C Hamano]

Jon Forrest <nobozo@gmail.com> writes:

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

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.

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

[Jon Forrest]

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

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

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

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