Junio C Hamano schrieb am 19.11.2014 um 22:43: > Jeff King <p...@peff.net> writes: > >> 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". > > Yup. I also find myself doing "git cmd -- \*.ext" to let Git, not > my shell, handle the patterns.
That is the correct way, of course. >> 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. > > ;-) > You can simply say "Michael" in your last subclause above :) I'm wondering whether that behaviour change (without --ignore-errors) is OK - I don't mind, but hey, I usually don't. I think it all comes down to the fact whether specifying an ignored file on the command line is considered an error or only "possibly a user error" we should dwim around. "git add" being plumbing, I'm somehow hesitant to change behaviour unless git is asked to ignore error. And if I'm hesitant already... oh wait. git add is declared porcelain? I would not have guessed without looking it up. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
