On Wed, Nov 19, 2014 at 03:52:33PM +0100, Michael J Gruber wrote: > "git add foo bar" adds neither foo nor bar when bar is ignored, but dies > to let the user recheck their command invocation. This becomes less > helpful when "git add foo.*" is subject to shell expansion and some of > the expanded files are ignored. > > "git add --ignore-errors" is supposed to ignore errors when indexing > some files and adds the others. It does ignore errors from actual > indexing attempts, but does not ignore the error "file is ignored" as > outlined above. > > Change "git add --ignore-errors foo bar" to add foo when bar is ignored, > i.e. to ignore the ignore error. > > Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> FWIW, your complaint and this new behavior makes sense to me. Typically I keep a very neat .gitignore file and just use "git add .", which _does_ ignore those files. The real problem here is that git cannot tell the difference between "the user explicitly asked for foo.aux, so we should complain" and "oops, foo.aux got caught in a shell expansion". I almost wonder if skipping ignored files should _always_ be a warning, not a hard error. I guess that has unpleasant side effects for scripts which call "git add XXX" and check the exit code, who may be unpleasantly surprised that they missed out on some content. Perhaps we could do a hybrid: add the files that were not ignored, but then still exit non-zero. Careful scripts need to check the exit status of "git add" anyway, and sloppy humans with over-broad wildcards typically do not care about the exit status. -Peff -- 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