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 en…
> 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".