Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> writes: >> I'd say a simplistic "ignore if zero is stored" or even "ignore this >> as one of the systems that shares this file writes crap in it" may >> be sufficient, and if this is a jGit specific issue, it might even >> make sense to introduce a single configuration variable with string >> "jgit" somewhere in its name and bypass the stat field comparison >> for known-problematic fields, instead of having the user know and >> list what stat fields need special attention. > > My first patch was something like that, just not using the word jgit. As > for what fields to ignore, it's something that can be configured by EGit > and documented on the EGit/JGit wiki. That configurability is a slipperly slope to drag us into giving users more complexity that does not help them very much, I suspect. Earlier somebody mentioned "size and mtime is often enough", so I think a single option core.looseStatInfo (substitute "loose" with short, minimum or whatever adjective that is more appropriate---I am not good at picking phrases, it sounds to me a way to more loosely define stat info cleanliness than we usually do) that makes us ignore all fields (regardless of their zero-ness) other than those two fields might not be a bad way to go. I do not offhand know if such a loose mode is too simple and make it excessively risky, though. -- 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