Frank Ammeter <git@xxxxxxxxxx> writes: > Am 15.04.2014 um 23:23 schrieb Junio C Hamano <gitster@xxxxxxxxx>: > >> Brandon McCaig <bamccaig@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html