On Wed, Aug 11, 2010 at 07:03, Greg Brockman <gdb@xxxxxxx> wrote: > Currently, 'git add' will complain about excluded files, even if they > are already tracked: > > $ mkdir dir && touch dir/file && cat > .gitignore <<< dir > $ git add -f dir/file > $ git status > ... > new file: dir/file > ... > $ git add dir/file > 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 > > This commit changes 'git add' to disregard excludes for tracked files > whose paths are explicitly specified on the command-line. So in the > above example, 'git add dir/file' no longer requires a '-f'. However, > 'git add dir' does. > > Signed-off-by: Greg Brockman <gdb@xxxxxxx> > --- > builtin/add.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > What do people think of this behavior? My motivation in writing this patch is > that I sometimes track files in an ignored directory, and it can be cumbersome > to remember to pass '-f' when adding them. Related commands such as 'git add -p' > and 'git commit -a' do not require a '-f' in this case, so it feels natural to me not > to require extra user confirmation when an explicit path has been provided. I like it. I keep a /etc in git with .gitignore "*". This would help a lot for use cases like that. Explicitly specifying a full path should override gitignore IMO. I think with some tests this should be ready to go. -- 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