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

From: Greg Brockman <gdb@mit.edu>
Date: Aug 12, 2010, 15:54 UTC
Message-ID: <AANLkTimODL6j11D6QuUX4b47GwFOVOXdqkhqrRfRaxmq@mail.gmail.com>
In-Reply-To: <vpqsk2kjks7.fsf@bauges.imag.fr>

Show 12 quoted lines

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

Show 6 quoted lines

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