Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > I _could_ understand if this functionality lived in, say, a new > command git-attr: > ... > (I have since read the thread in which Junio's suggested[1] that > git-add could house this functionality, but it still feels too > high-level.) If this were part of a hypothetical "git attr" command, I would have a hard time understanding it. I would view the "attr" as attributes attached to each path, telling various things about the path, one of which may be how contents are handled between Git and the file on the filesystem. In other words, "attr" is _not_ contents; it is a set of attributes attached to path that house the contents. What we are correcting here at this point in the expected usecase is not an attribute. We are correting the contents, and between the two potential sources of "the right version" of the contents, the user tells that the filesystem is the right one, so "add" is used to correct mistakes in the index based on what is in the filesystem (if we were correcting the other way, like Jonathan said in the message in the thread you read, "checkout" would be used to correct the filesystem version using what is in the index).
