Robin Rosenberg <robin.rosenb...@dewire.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html