On Wed, 17 May 2006, Junio C Hamano wrote: > > If you give a pattern that would match two files but one of them > were hidden by .gitignore, this approach would not help you > much. Correct. On the other hand, what could you do? I think that the common case for that is literally something like git add dirname/ or git add file* and it turns out that there are object files under the directory, or that there's a file.c, file.h _and_ a already-compiled file.o file. Under both of those circumstances (one pattern that matches multiple files but ignores others - or several different patterns where _some_ of the patterns are ignored), we actually do what I think is the only sane thing. Namely to just silently add everything that makes sense to add. > Even if we wanted to say something like "if the user explicitly > tells us to add etc/mtab~ by spelling it out, we should ignore > *~ entry in .gitignore", the shell expansion bites us because it > is done before we get to what the user give us. We cannot > distinguish that with the user typing etc/?tab* for example. Right. The only case that we cando anything at all about is really the case where we didn't add anything at all, and then we might reasonably ask "do you know what the heck you're doing". That's kind of what my last patch did. It's a total special case, but it's the _only_ special case that I can see that is at all relevant (ie in all other cases it would just be annoying as _hell_ if we started talking about how we're ignoring object files. Of _course_ we're ignoring them, and that's why they are listed in .gitignore). So I'd love to have the built-in "git add", but quite frankly, if you drop that last patch as "too ugly to live", I certainly won't complain. I sent it out more as a "we -could- do this" thing rather than anything more serious. Linus - : 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