Re: [RFC/PATCH] git-add: Don't exclude explicitly-specified tracked files

Greg Brockman [off-list ref] writes:

quoted

quoted

This commit changes 'git add' to disregard excludes for tracked files
whose paths are explicitly specified on the command-line.

I don't think you need this to solve the problem,

This remains (see below) ...

quoted

and as Junio said, that would make "git add dir/*" add all the
ignored files, which would make -f essentially useless.

... but this is actually wrong, yes. Your commit message states

| This commit changes 'git add' to disregard excludes for tracked
| files whose paths are explicitly specified on the command-line.

I had missed the "tracked files whose ..." part, and focused on the
"path is explicitely specified on the command-line".

And actually, all you need is to see whether the file is tracked or
not, and not whether it's been given from the command-line. With your
patch, I get:

$ git init git
Initialized empty Git repository in /tmp/git/.git/
$ cd git
$ mkdir dir
$ touch dir/file
$ echo dir > .gitignore
$ git add -f dir/file
$ echo content >> dir/file
$ git add dir/file
$ git add dir/f*    # <--- shell globing

Up to now, everything OK. But:

$ git add dir/f\*   # <--- Git globing.
The following paths are ignored by one of your .gitignore files:
dir
Use -f if you really want to add them.
fatal: no files added

I think Git should not apply any .gitignore rule to already-tracked
files, whether they are given from the command-line explicitely or
through globbing.

One case which can be discussed:

$ git add dir
The following paths are ignored by one of your .gitignore files:
dir
Use -f if you really want to add them.
fatal: no files added

I don't think I should need a -f flag here either, since dir/ contains
only tracked files. But I don't care much here.

Incidentally, I noticed that 'git add dir/file' for ignored dir worked
fine in an older version of git.  'git bisect' reveals that the
behavior I would like to change was introduced in 29209cb.  From the
commit message, I get the sense that this particular behavior was not
actually intentional (someone please correct me if I'm missing
something).

My understanding is that the goal was to reject the first "git add
subdir/file", but not subsequent ones.

I'd suggest that you write a first patch introducing new tests,
possibly marked as test_expect_failure, so that people can at least
agree on the desired behavior, and then an implementation could
follow.

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