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

[Greg Brockman <gdb@MIT.EDU>]

>> Currently, 'git add' will complain about excluded files, even if they
>> are already tracked:
>
> This is not exactly true:
>
> $ echo '*.pdf' > .gitignore; touch foo.pdf; git add -f foo.pdf
> $ echo content >> foo.pdf; git add foo.pdf
>
> Here, the second "git add" didn't need the -f flag.
>
> So, your problem is not about already-tracked exclude files, but it is
> about already-tracked files in an excluded directory.
Good catch.  My commit message is definitely wrong.

>> 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, and as Junio said,
> that would make "git add dir/*" add all the ignored files, which would
> make -f essentially useless.
I respectfully disagree with this assessment, however.

First of all, as you point out 'git add foo.pdf' works where foo.pdf
has been explicitly ignored, while in contrast 'git add dir/file'
fails when file has only been indirectly ignored because it is in an
ignored directory.  In the former case, the user explicitly specified
a policy for that file.  In the later case, the policy is only
indirectly expressed because that file happens to be in an ignored
directory; in my and Ævar's use cases what we mean is "I only care
about a few files in a big directory and don't feel like writing out a
.gitignore entry for each one".  So it doesn't make sense to me to
allow the user to add the file in the first place (whether by a 'git
add foo.pdf' or a 'git add f*') but not the second.  Perhaps the
answer is to swing in the opposite direction of this patch series and
make 'git add foo.pdf' fail as well, but I must ask what we'd be
defending against... it seems the only reason is to allow the user to
maintain local changes to a tracked file, but as I've stated many
other tools don't seem to similarly respect the .gitignore.

Secondly, I don't think this makes '-f' useless.  '-f' would still be
used to initially add an untracked file to the index.  So this would
maintain an invariant that no ignored files are tracked unless the
user has specified a '-f' for it in the past.

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

Thanks,

Greg