Robin Rosenberg [off-list ref] writes:
quoted
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.
Junio C Hamano wrote:
Robin Rosenberg [off-list ref] writes:
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.
At one point, I used to build (and test) the MSVC version of git on
cygwin, which leads to exactly the same problem. So, this is not just
an EGit/JGit vs c-git issue, although there can't be many people that
will have this problem. (Mixing the MinGW and cygwin versions on the
same repo will also have this problem).
I had a patch which, essentially, did what you suggest above; ie ignore
everything other than size and mtime, *including* ignoring the zero-ness
in the index. (I just don't understand why you would think of doing
otherwise!! ;-) ). As part of that patch, I also suppressed the "empty diff"
output that used to be shown for stat-dirty files (that's been fixed now
right?), otherwise using gitk was a pain.
[BTW, given the "schizophrenic stat" functions on cygwin, you can have
this problem with the cygwin version of git - all on it's lonesome!]
I can't help with naming, BTW, since I called the config variable
"core.ramsay-stat". :-P
I do not offhand know if such a loose mode is too simple and make it
excessively risky, though.
I suspect it would be fine ... *however*, I never sent my patch because
I didn't think there would be many idiots^H^H^H^H^H^H pioneers like me! :-D
ATB,
Ramsay Jones
----- Ursprungligt meddelande -----
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.
Would something like this be good?
core.statinfo =
default = all fields
minimal = whole seconds of mtime and size
medium = seconds, nanos of mtime and size
nonzero = all non-zero fields
-- robin