[comex]

This seems like it should be considered a bug in git. If a changed ctime would otherwise cause a failure, checking at that point whether the content actually changed shouldn't be an expensive operation, and since git does not track extended attributes or file flags (I'm guessing the problem is related to one of the two), a change in which updates ctime, such a change should not cause spurious failure.

I don't know enough about git to say whether my suggested fix is equivalent to turning trustctime off by default.

[fr0sty]

> checking at that point whether the content actually changed shouldn't be an expensive operation

This is only true if you have very little "content".