In a727fea2 ("locking: remove write permission for ignored files",
2018-08-20), we learned to set and clear the read-only attribute on
ignored files that match the lockable pattern, since "git lfs lock"
operates on pathspecs, not actual files.
However, in doing so, we caused a regression for people who have ignored
files (such as build files) which match the lockable pattern, but should
not have their permissions modified. Since there is no easy way for us
to know if the user would like their files modified, add a config option
to control this behavior, and leave it at the historical (i.e.,
pre-a727fea2) default, off. Add documentation accordingly.
Choosing the historical behavior is compatible with the most existing
use cases and preserves the behavior people expect with Git, which is
that it does not touch ignored files.
44fb9ecdc7