Karsten Blees <karsten.blees@xxxxxxxxx> writes: > Wouldn't it be better to just strip the BOM on commit, e.g. via a > clean filter or pre-commit hook (as suggested in [1])? The users can do whatever they want and if they think having a BOM in these files is a bad idea, I'd encourage them to use whatever means to ensure that. The code and history hygiene is a good thing. But you should realize that $HOME/.gitconfig, $GIT_DIR/info/exclude, $GIT_DIR/config, etc. are not even committed files in the first place. These are not even defined to be "UTF-8 only" by us. Their contents is entirely up to the end users. Here with these changes, we are only being nice to the users by stripping a well-known two-byte sequence that is known to be left commonly by some tools users would use. In a sense, this is the same degree of niceness that we strip the CR at the end of the line before LF. Just like you _could_ have said these files must be encoded in UTF-8 and must not have BOM at the beginning, we _could_ have defined that these files must be recorded with LF end-of-line. But obviously we don't, as there is no need to make lives of end users unnecessarily more complex, and it is easy to help users use both LF and CRLF with simply stripping on our reader's side. We do this BOM stripping for the same reason to make it easier for users. -- 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