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

[Junio C Hamano <gitster@pobox.com>]

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.