Frank Ammeter <g...@ammeter.ch> writes: > Am 15.04.2014 um 23:23 schrieb Junio C Hamano <gits...@pobox.com>: > >> Brandon McCaig <bamcc...@gmail.com> writes: >> >>> That is for your benefit, and for easily sharing that configuration >>> with collaborators. Git only cares that the file exists in your >>> working tree at run-time. >> >> It is a lot more than "for sharing". If you made .gitignore only >> effective after it gets committed, you cannot test your updated >> version of .gitignore is correct before committing the change. > > Ok, I can follow that logic for .gitignore, but I was talking about > .gitattributes...
They are conceptually the same thing, so if you can follow the logic for .gitignore, you already can follow the logic for .gitattributes. The only two readons we have a separate .gitignore are because other SCMs had a similar mechanism, and because it came before attributes. If we didn't have these two constraints, it would have made a lot more sense to express "this path is to be ignored" by setting "ignored" attribute. -- 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
