Frank Ammeter <> writes:

> Am 15.04.2014 um 23:23 schrieb Junio C Hamano <>:
>> Brandon McCaig <> 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
More majordomo info at

Reply via email to