[PATCH] Use find instead of perl in t5000 to get file modification time

[PATCH] Use find instead of perl in t5000 to get file modification time

[Alex Riesen]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

The test "validate file modification time" was broken on admittedly broken
combination of Windows, Cygwin, and ActiveState Perl. Something (I blame
ActiveState) of the three is very confused about what time zone
to use for the modification time.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---

I could not find what exactly does the ActiveState's Perl use for its stat
implementation (and honestly, have no motivation to look harder).
It seems to honor TZ, but the produced time does not seem to be either
local or GMT.

There can be a problem with "-printf": Open Group SUS does not specify
-printf for find(1), so it is probably a problem somewhere. I just don't know.

There is always a fallback, which is to write a small program which calls
native stat(2). Or modify test-chmtime to just print mtime when asked.

 t/t5000-tar-tree.sh |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-find-instead-of-perl-in-t5000-to-get-file-modifi.patch --]
[-- Type: text/x-diff; name=0001-Use-find-instead-of-perl-in-t5000-to-get-file-modifi.patch, Size: 1470 bytes --]

From 1bd8a9445d9bba463fb1edb758d7760fbf53b03a Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 29 Oct 2008 10:22:15 +0100
Subject: [PATCH] Use find instead of perl in t5000 to get file modification time

The test was broken on admittedly broken combination of Windows, Cygwin,
and ActiveState Perl.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
 t/t5000-tar-tree.sh |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 0f27d73..4eabebd 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -26,6 +26,8 @@ commit id embedding:
 
 . ./test-lib.sh
 UNZIP=${UNZIP:-unzip}
+TZ=GMT
+export TZ
 
 SUBSTFORMAT=%H%n
 
@@ -54,7 +56,7 @@ test_expect_success \
      find a -type l | xargs git update-index --add &&
      treeid=`git write-tree` &&
      echo $treeid >treeid &&
-     git update-ref HEAD $(TZ=GMT GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
+     git update-ref HEAD $(GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
      git commit-tree $treeid </dev/null)'
 
 test_expect_success \
@@ -90,7 +92,7 @@ test_expect_success \
     'validate file modification time' \
     'mkdir extract &&
      "$TAR" xf b.tar -C extract a/a &&
-     perl -e '\''print((stat("extract/a/a"))[9], "\n")'\'' >b.mtime &&
+     find extract/a/a -printf "%T@\\n" >b.mtime &&
      echo "1117231200" >expected.mtime &&
      diff expected.mtime b.mtime'
 
-- 
1.6.0.3.549.gb475d

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Jeff King]

On Wed, Oct 29, 2008 at 11:38:32AM +0100, Alex Riesen wrote:

> There can be a problem with "-printf": Open Group SUS does not specify
> -printf for find(1), so it is probably a problem somewhere. I just don't know.
> [...]
> +     find extract/a/a -printf "%T@\\n" >b.mtime &&

$ uname -sr
FreeBSD 6.1-RELEASE-p17-jc1
$ find . -printf "%T@\\n"
find: -printf: unknown option

> There is always a fallback, which is to write a small program which calls
> native stat(2). Or modify test-chmtime to just print mtime when asked.

I think that makes the most sense.

-Peff

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Sam Vilain]

On Wed, 2008-10-29 at 11:38 +0100, Alex Riesen wrote:
> I could not find what exactly does the ActiveState's Perl use for its stat
> implementation (and honestly, have no motivation to look harder).
> It seems to honor TZ, but the produced time does not seem to be either
> local or GMT.

See, the difference is that the perl is portable and your patch isn't.

Can you at least reveal how far out the value printed by the perl
fragment was from the expected value, and what your TZ offset is in
seconds.  It might be pointing to a deeper problem that could affect
more than just this test case.

Sam.

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Alex Riesen]

Jeff King, Wed, Oct 29, 2008 22:54:45 +0100:
> On Wed, Oct 29, 2008 at 11:38:32AM +0100, Alex Riesen wrote:
> 
> > There can be a problem with "-printf": Open Group SUS does not specify
> > -printf for find(1), so it is probably a problem somewhere. I just don't know.
> > [...]
> > +     find extract/a/a -printf "%T@\\n" >b.mtime &&
> 
> $ uname -sr
> FreeBSD 6.1-RELEASE-p17-jc1
> $ find . -printf "%T@\\n"
> find: -printf: unknown option
> 
> > There is always a fallback, which is to write a small program which calls
> > native stat(2). Or modify test-chmtime to just print mtime when asked.
> 
> I think that makes the most sense.
> 

Ok, will do.

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Alex Riesen]

Sam Vilain, Thu, Oct 30, 2008 06:29:14 +0100:
> On Wed, 2008-10-29 at 11:38 +0100, Alex Riesen wrote:
> > I could not find what exactly does the ActiveState's Perl use for its stat
> > implementation (and honestly, have no motivation to look harder).
> > It seems to honor TZ, but the produced time does not seem to be either
> > local or GMT.
> 
> See, the difference is that the perl is portable and your patch isn't.

ActiveState Perl on Windows is portable? To another windows, maybe.

> Can you at least reveal how far out the value printed by the perl
> fragment was from the expected value, and what your TZ offset is in
> seconds.  It might be pointing to a deeper problem that could affect
> more than just this test case.

I tried TZ set to CET (my zone), GMT, and UTC. The difference was from
1200 sec to 3600.

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Peter Harris]

On Fri, Oct 31, 2008 at 3:00 AM, Alex Riesen wrote:
> Sam Vilain, Thu, Oct 30, 2008 06:29:14 +0100:
>> On Wed, 2008-10-29 at 11:38 +0100, Alex Riesen wrote:
>> > I could not find what exactly does the ActiveState's Perl use for its stat
>> > implementation (and honestly, have no motivation to look harder).
>> > It seems to honor TZ, but the produced time does not seem to be either
>> > local or GMT.
>>
>> See, the difference is that the perl is portable and your patch isn't.
>
> ActiveState Perl on Windows is portable? To another windows, maybe.

Quite aside from missing the point (which is that Vanilla Perl runs
everywhere, including Windows[1]), this is also factually incorrect. A
quick check of the ActiveState website would reveal ActivePerl
downloads for AIX, Linux (x86 and x86-64), Solaris (x86, SPARC, and
SPARC64), MacOSX (x86 and PPC), and source code, in addition to
Windows.

Looks pretty portable to me.

Peter Harris

[1] http://vanillaperl.com/

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Alex Riesen]

2008/10/31 Peter Harris <git@peter.is-a-geek.org>:
> On Fri, Oct 31, 2008 at 3:00 AM, Alex Riesen wrote:
>> Sam Vilain, Thu, Oct 30, 2008 06:29:14 +0100:
>>> On Wed, 2008-10-29 at 11:38 +0100, Alex Riesen wrote:
>>> > I could not find what exactly does the ActiveState's Perl use for its stat
>>> > implementation (and honestly, have no motivation to look harder).
>>> > It seems to honor TZ, but the produced time does not seem to be either
>>> > local or GMT.
>>>
>>> See, the difference is that the perl is portable and your patch isn't.
>>
>> ActiveState Perl on Windows is portable? To another windows, maybe.
>
> Quite aside from missing the point (which is that Vanilla Perl runs
> everywhere, including Windows[1]), this is also factually incorrect.

Ok, it is (almost: "Vanilla Perl is experimental and is not intended for
production purposes". Well, I need it exactly for production purposes!)

> A quick check of the ActiveState website would reveal ActivePerl
> downloads for AIX, Linux (x86 and x86-64), Solaris (x86, SPARC, and
> SPARC64), MacOSX (x86 and PPC), and source code, in addition to
> Windows.

what's the point of that, I wonder... Just to admit they broke the original
source beyond all repair on one platform (windows) so now they
have provide their poor customers with the same broken version
on all the other platforms, because they complained about incompatibilities.

So Perl is portable. ActiveState Perl may look portable. They just don't
seem to be compatible enough. Even then, the Git's test suite and some
scripts (I have no use for git-svn on Windows) do very good job to be usable
even if the portable dependency replaced with something else. I'm trying to
keep it at that because I personally have no choice.

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Johannes Schindelin]

Hi,

On Fri, 31 Oct 2008, Alex Riesen wrote:

> ActiveState Perl on Windows is portable? To another windows, maybe.

/me wonders why you could not use the Perl that ships with Git for 
Windows, at least for the purposes of Git.

Ciao,
Dscho

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Alex Riesen]

Johannes Schindelin, Fri, Oct 31, 2008 23:14:59 +0100:
> Hi,
> 
> On Fri, 31 Oct 2008, Alex Riesen wrote:
> 
> > ActiveState Perl on Windows is portable? To another windows, maybe.
> 
> /me wonders why you could not use the Perl that ships with Git for 
> Windows, at least for the purposes of Git.

Corporate policy and very-very incompetent IT service. Besides being
illegal to install actually usable software, there are some of
internal programs which are quite sensitive to perl (any other perl)
appearing anywhere on disk, not to mention PATH (the build system, for
one). Same for cygwin revisions.

I tried using other perl and more modern cygwin, and it can be made to
work, but it is cumbersome and boring. And one more thing to reinstall
after IT wipes your computer because you've got a new disk or they
decided you need winxp instead of w2k, or something else... So I'm
just trying reduce effort I put into what I'm not supposed to do at
work anyway.

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Johannes Schindelin]

Hi,

On Sat, 1 Nov 2008, Alex Riesen wrote:

> Johannes Schindelin, Fri, Oct 31, 2008 23:14:59 +0100:
> 
> > On Fri, 31 Oct 2008, Alex Riesen wrote:
> > 
> > > ActiveState Perl on Windows is portable? To another windows, maybe.
> > 
> > /me wonders why you could not use the Perl that ships with Git for 
> > Windows, at least for the purposes of Git.
> 
> Corporate policy and very-very incompetent IT service. Besides being 
> illegal to install actually usable software, there are some of internal 
> programs which are quite sensitive to perl (any other perl) appearing 
> anywhere on disk, not to mention PATH (the build system, for one). Same 
> for cygwin revisions.
> 
> I tried using other perl and more modern cygwin, and it can be made to 
> work, but it is cumbersome and boring. And one more thing to reinstall 
> after IT wipes your computer because you've got a new disk or they 
> decided you need winxp instead of w2k, or something else... So I'm just 
> trying reduce effort I put into what I'm not supposed to do at work 
> anyway.

Well, if you install Git for Windows (as opposed to cygwin), it is minimum 
hassle, and Perl is delivered right with it.

Ciao,
Dscho

P.S.: some guys at the GSoC mentor summit convinced me in at least trying 
to fix _their_ problems on msysGit, so chances are good I'll fix issues 
you would encounter in the same run.

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Alex Riesen]

Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> 
> Well, if you install Git for Windows (as opposed to cygwin), it is minimum 
> hassle, and Perl is delivered right with it.
> 

I'd like to try it again, but weren't ther some fatal problems with
cygwin1.dll being in PATH? I always work either in Cygwin's bash or
just have to have it in PATH, because of the build environment even
being strictly Windows based (case-insensitive and alike) just have to
use sane tooling in its scripts.

> 
> P.S.: some guys at the GSoC mentor summit convinced me in at least trying 
> to fix _their_ problems on msysGit, so chances are good I'll fix issues 
> you would encounter in the same run.
> 

Do you still plan to distribute MinGW with it? It's very nice to be
able to track Junio's repo, have own branches and rebuild Git from
time to time. For me, at least.

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Johannes Schindelin]

Hi,

On Sat, 1 Nov 2008, Alex Riesen wrote:

> Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> > 
> > Well, if you install Git for Windows (as opposed to cygwin), it is 
> > minimum hassle, and Perl is delivered right with it.
> 
> I'd like to try it again, but weren't ther some fatal problems with 
> cygwin1.dll being in PATH? I always work either in Cygwin's bash or just 
> have to have it in PATH, because of the build environment even being 
> strictly Windows based (case-insensitive and alike) just have to use 
> sane tooling in its scripts.

I was talking about Git for Windows, i.e. the result of msysGit (as 
opposed to Git in Cygwin).

So no, there have not been any conflicts with cygwin1.dll in the PATH, as 
far as I can recall.  There have been problems with shell utilities being 
found in the Cygwin PATH before being found in the MSys PATH, but I 
thought we just prepended the MSys PATH to avoid that.  Haven't checked, 
though.

> > P.S.: some guys at the GSoC mentor summit convinced me in at least 
> > trying to fix _their_ problems on msysGit, so chances are good I'll 
> > fix issues you would encounter in the same run.
> 
> Do you still plan to distribute MinGW with it? It's very nice to be able 
> to track Junio's repo, have own branches and rebuild Git from time to 
> time. For me, at least.

You mean to distribute a minimal MSys environment where you have bash?  
Yes, we have to do that, as there are still too many important parts of 
Git written in Shell.

Ciao,
Dscho

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Alex Riesen]

Johannes Schindelin, Sat, Nov 01, 2008 21:37:14 +0100:
> On Sat, 1 Nov 2008, Alex Riesen wrote:
> > Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> > > 
> > > Well, if you install Git for Windows (as opposed to cygwin), it is 
> > > minimum hassle, and Perl is delivered right with it.
> > 
> > I'd like to try it again, but weren't ther some fatal problems with 
> > cygwin1.dll being in PATH? I always work either in Cygwin's bash or just 
> > have to have it in PATH, because of the build environment even being 
> > strictly Windows based (case-insensitive and alike) just have to use 
> > sane tooling in its scripts.
> 
> I was talking about Git for Windows, i.e. the result of msysGit (as 
> opposed to Git in Cygwin).
> 
> So no, there have not been any conflicts with cygwin1.dll in the PATH, as 
> far as I can recall.  There have been problems with shell utilities being 
> found in the Cygwin PATH before being found in the MSys PATH, but I 
> thought we just prepended the MSys PATH to avoid that.  Haven't checked, 
> though.

Ok, I'll give it a try.

> > > P.S.: some guys at the GSoC mentor summit convinced me in at least 
> > > trying to fix _their_ problems on msysGit, so chances are good I'll 
> > > fix issues you would encounter in the same run.
> > 
> > Do you still plan to distribute MinGW with it? It's very nice to be able 
> > to track Junio's repo, have own branches and rebuild Git from time to 
> > time. For me, at least.
> 
> You mean to distribute a minimal MSys environment where you have bash?  
> Yes, we have to do that, as there are still too many important parts of 
> Git written in Shell.

No, the mingw compiler and libraries. I vaguely remember some talking
about including the build environment into Git distribution.

Re: [PATCH] Use find instead of perl in t5000 to get file modification time

[Johannes Schindelin]

Hi,

On Sun, 2 Nov 2008, Alex Riesen wrote:

> Johannes Schindelin, Sat, Nov 01, 2008 21:37:14 +0100:
> > On Sat, 1 Nov 2008, Alex Riesen wrote:
> > > Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> > > > 
> > > > P.S.: some guys at the GSoC mentor summit convinced me in at least 
> > > > trying to fix _their_ problems on msysGit, so chances are good 
> > > > I'll fix issues you would encounter in the same run.
> > > 
> > > Do you still plan to distribute MinGW with it? It's very nice to be 
> > > able to track Junio's repo, have own branches and rebuild Git from 
> > > time to time. For me, at least.
> > 
> > You mean to distribute a minimal MSys environment where you have bash?  
> > Yes, we have to do that, as there are still too many important parts 
> > of Git written in Shell.
> 
> No, the mingw compiler and libraries. I vaguely remember some talking 
> about including the build environment into Git distribution.

We do that already for a long time.  Basically, we have two distributions: 
Git for Windows (for the end user) and msysGit (for the developer wanting 
to work _on_ Git).  Actually, msysGit was there first.

Hth,
Dscho