On Mon, Nov 17, 2014 at 12:12:25AM +0000, Ryan Jacobs wrote: > Alberto Fanjul Alonso <albertofanjul <at> gmail.com> writes: > > > > git ignore <whatever> adds <whatever> to .git/info/exclude > > This should be "git exclude" not "git ignore". > Difference between the two: http://stackoverflow.com/questions/10066749/git- > excludes-vs-ignores I am not sure that the name difference is all that meaningful. Yes, we call the repo-wide file .git/info/exclude and the in-tree ones .gitignore, but I do not know if the distinction is more than historical accident. > I'd second the notion of a "git ignore", however it would have to modify the > `.gitignore` not `.git/info/exclude`. And I think this is a good reason why we do not have a "git ignore" tool to write such things. If I say "git ignore foo" should it go into .git/info/exclude or .gitignore? If the latter, should it be "foo" to match everywhere, or "/foo" to match only the single path at the root? If the file is "subdir/foo", should it go as "/subdir/foo" into the top-level ".gitignore", or as "foo" into "subdir/.gitignore"? If you ignore "foo.o" and "bar.o", should we suggest that you ignore "*.o" instead? Trying to accomodate all of those possibilities in a command-line tool is hard, and probably counter-productive. We already have a simple domain-specific language for specifying .gitignore files. You can just try to cover a common case, like "always put the full slash-prefixed path into the top-level .gitignore". But then I wonder if "git ignore" is really adding much value, as it is just a thin wrapper around "echo". -Peff PS The more interesting case to automate (to me, anyway) is _checking_ paths against the hand-written .gitignore rules, which is complicated to do by hand. You can do that already with "git check-ignore". -- 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