On Fri, 28 Aug 2009, Jeff King wrote:
> On Fri, Aug 28, 2009 at 09:58:27AM +0200, Alex Riesen wrote:
>
> > > I couldn't find any tests related to relative date processing, so it
> > > would be really nice to have some. But I'm not sure of the best way to
> > > do it without dealing with race conditions. Annoyingly, show_date calls
> > > gettimeofday at a pretty low level, so there isn't a way of
> > > instrumenting it short of LD_PRELOAD trickery (which is probably not
> > > very portable).
> >
> > Maybe better prepare the _test_ so that it uses current time and time
> > arithmetics then put yet another cludge in operational code? Especially
> > when we already have a greate number of GIT_ environment variables,
> > documented nowhere, with effects not immediately obvious:
>
> But that's the point: you can't do that without a race condition. Your
> test gets a sense of the current time, then runs git, which checks the
> current time again. How many seconds elapsed between the two checks?
>
> I guess it is good enough for testing large time spans, but I was hoping
> for a comprehensive time test.
I agree with your concern. This is why I created the --index-version
switch to pack-objects.
However I was hoping for a current time trickery solution that could
live in test-date.c instead of interfering with the main code in such a
way.
Did a quick test to override the library version:
diff --git a/test-date.c b/test-date.c
index 62e8f23..0bcd0c9 100644
--- a/test-date.c
+++ b/test-date.c
@@ -1,5 +1,10 @@
#include "cache.h"
+int gettimeofday(struct timeval *tv, struct timezone *tz)
+{
+ return 0;
+}
+
int main(int argc, char **argv)
{
int i;
Result:
$ ./test-date now
now -> bad -> Wed Dec 31 19:00:00 1969
now -> Tue Jan 22 10:48:24 10199
So this seems to work. ;-)
Nicolas
--
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