From: Junio C Hamano Date: Thu, 15 Jan 2026 16:55:34 GMT Subject: Re: Repost: Inconsistent Behavior in 'git add' (git 2.52.0)? Message-ID: In-Reply-To: <12239ac3-bc9c-4484-8633-a255a706011c@gmail.com> Jon Forrest 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.