Thread (1 message) 1 message, 1 author, 2016-06-15

Re: wrong handling of text git attribute leading to files incorrectly reported as modified

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:00:42

Frank Ammeter [off-list ref] writes:
Am 15.04.2014 um 23:23 schrieb Junio C Hamano [off-list ref]:
quoted
Brandon McCaig [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help