Greg Brockman <gdb@xxxxxxx> writes: >>> 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) ... >> 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html