Towards a new Git4Win version

[Johannes Schindelin]

Hi,

our Git for Windows installer is already a few months old. Anything you
want me to merge? My plan is to merge mingw.git's 'master' after finding
out what was the most recent commit merging a tagged upstream version.

Ciao,
Dscho

[Erik Faye-Lund]

I'd like to see my daemon-series in the next installer, if I can get
it ready-enough in time. I think it makes sense to let the Windows
users play around with it before eventually getting it into git.git.

However, it still needs a bit of work, and I'm a bit held up with
other things now (dayjob).

--
Erik "kusma" Faye-Lund

[Robin Rosenberg]

I'd love to see my UNC patch in there, provided it gets approved shortly. Not
being able to push anywhere I want to without mapping a drive letter and
restart all msysgit instances has been a PITA.

-- robin

[Johannes Sixt]

The most recent commit in mingw.git merging a tagged upstream version is

v1.7.0-rc0-1014-gf2cce4c

as of today ;)

-- Hannes

[Pat Thoyts]

2010/1/25 Johannes Schindelin <Johannes....@gmx.de>:

> our Git for Windows installer is already a few months old.  Anything you
> want me to merge?  My plan is to merge mingw.git's 'master' after finding
> out what was the most recent commit merging a tagged upstream version.

My themed Tk patch for git-gui might be worth it as this is most
effective on Windows. I will get on with updating and reissuing that
this evening and maybe it will get applied upstream anyway.

Pat Thoyts

[Johannes Schindelin]

Hi,

Oh, so you do not tag commits in mingw.git anymore?

In any case, I just merged mingw/master, and if it does not take too long
to compile in the virtual machine, will push out 'devel' before I go to
bed.

Ciao,
Dscho

[Heiko Voigt]

How about bringing cheetah into the installer? I got a hint from
Sebastian that we could throw his an my changes together soonish. So
maybe you could put this on the list and merge once we get a final
branch ready?

What is your time frame for a new installer? Releasing with 1.7.0?

cheers Heiko

[Sebastian Schuberth]

On Thu, Jan 28, 2010 at 23:15, Heiko Voigt <hvo...@hvoigt.net> wrote:

>> our Git for Windows installer is already a few months old.  Anything you
>> want me to merge?  My plan is to merge mingw.git's 'master' after finding
>> out what was the most recent commit merging a tagged upstream version.
>
> How about bringing cheetah into the installer? I got a hint from
> Sebastian that we could throw his an my changes together soonish. So
> maybe you could put this on the list and merge once we get a final
> branch ready?

Yes, I'd like to get ss/installer-improvements merged, and if I don't
manage to incorporate Heiko's changes, probably merge his
hv/cheetah-installer first.

Also, there is at least one patch from me that did not yet make it
into git.git, but for which we already closed the bug report (issue
385).

Dscho, what about the issue251 and issue369 branches? For the latter,
I think I sent you some feeback that the line endings in etc/profile
seem borked.

--
Sebastian Schuberth

[Johannes Schindelin]

Hi,

On Thu, 28 Jan 2010, Heiko Voigt wrote:

> On Mon, Jan 25, 2010 at 03:43:31PM +0100, Johannes Schindelin wrote:
>
> > our Git for Windows installer is already a few months old. Anything
> > you want me to merge? My plan is to merge mingw.git's 'master' after
> > finding out what was the most recent commit merging a tagged upstream
> > version.
>
> How about bringing cheetah into the installer? I got a hint from
> Sebastian that we could throw his an my changes together soonish. So
> maybe you could put this on the list and merge once we get a final
> branch ready?

Good idea.

> What is your time frame for a new installer? Releasing with 1.7.0?

Actually, I would have loved to release something last Thursday, but that
was just too much to ask for.

So I guess 1.7.0 it is.

Ciao,
Dscho

[Johannes Schindelin]

Hi,

On Thu, 28 Jan 2010, Sebastian Schuberth wrote:

> On Thu, Jan 28, 2010 at 23:15, Heiko Voigt <hvo...@hvoigt.net> wrote:
>
> >> our Git for Windows installer is already a few months old.  Anything
> >> you want me to merge?  My plan is to merge mingw.git's 'master' after
> >> finding out what was the most recent commit merging a tagged upstream
> >> version.
> >
> > How about bringing cheetah into the installer? I got a hint from
> > Sebastian that we could throw his an my changes together soonish. So
> > maybe you could put this on the list and merge once we get a final
> > branch ready?
>
> Yes, I'd like to get ss/installer-improvements merged, and if I don't
> manage to incorporate Heiko's changes, probably merge his
> hv/cheetah-installer first.

Okay.

> Also, there is at least one patch from me that did not yet make it into
> git.git, but for which we already closed the bug report (issue 385).
>
> Dscho, what about the issue251 and issue369 branches? For the latter,
> I think I sent you some feeback that the line endings in etc/profile
> seem borked.

Sorry, I did not have as much Git time as I would have loved to; I will
try to set aside some time tomorrow. Thanks for the nudge!

Ciao,
Dscho

[Johannes Schindelin]

Hi,

first bad message of the day: I did not manage to find any Git time
yesterday (Friday).

On Thu, 28 Jan 2010, Sebastian Schuberth wrote:

> On Thu, Jan 28, 2010 at 23:15, Heiko Voigt <hvo...@hvoigt.net> wrote:
>

> >> our Git for Windows installer is already a few months old. ï¿œAnything you
> >> want me to merge? ï¿œMy plan is to merge mingw.git's 'master' after finding

> >> out what was the most recent commit merging a tagged upstream version.
> >
> > How about bringing cheetah into the installer? I got a hint from
> > Sebastian that we could throw his an my changes together soonish. So
> > maybe you could put this on the list and merge once we get a final
> > branch ready?
>
> Yes, I'd like to get ss/installer-improvements merged, and if I don't
> manage to incorporate Heiko's changes, probably merge his
> hv/cheetah-installer first.
>
> Also, there is at least one patch from me that did not yet make it
> into git.git, but for which we already closed the bug report (issue
> 385).

Second bad message of the day: I do not remember where this fix is. Can
you just apply to 4msysgit.git's master, please?

> Dscho, what about the issue251 and issue369 branches? For the latter, I
> think I sent you some feeback that the line endings in etc/profile seem
> borked.

Sorry, I just changed the line endings.

And yes, I would like to merge issue251 and issue369 before releasing. But
here comes the third really bad message of the day: I only have access to
Windows in a virtual machine since a couple of weeks ago. And this virtual
machine churns for over 24 hours now to run the Git test suite.

So I will rely on you guys to run the test suite and find bugs and fix
them, because I just take too long.

Ciao,
Dscho

[Johannes Schindelin]

Hannes,

I just remembered that I pushed out the 'no-fstab-thread' branch for you,
but you never came back to me (or I missed the reply). What about it?
Should I merge?

Ciao,
Dscho

[Junio C Hamano]

Johannes Schindelin <Johannes....@gmx.de> writes:

>> Also, there is at least one patch from me that did not yet make it
>> into git.git, but for which we already closed the bug report (issue
>> 385).
>
> Second bad message of the day: I do not remember where this fix is. Can
> you just apply to 4msysgit.git's master, please?

I think Sebastian means this one:

From: Sebastian Schuberth <sschu...@gmail.com>
Subject: Re: [PATCH] If deriving SVN_SSH from GIT_SSH on msys, also add quotes
Date: Sat, 23 Jan 2010 15:20:28 +0100
Message-ID: <4B5B05AC...@gmail.com>

(aka $gmane/137841).

I'll queue it myself (Eric Cc'ed) before 1.7.0-rc1.

[Johannes Schindelin]

Hi,

Thanks, I also applied it to 4msysgit.git.

Ciao,
Dscho

[Sebastian Schuberth]

On Sat, Jan 30, 2010 at 04:55, Johannes Schindelin
<Johannes....@gmx.de> wrote:

>> >> Also, there is at least one patch from me that did not yet make it
>> >> into git.git, but for which we already closed the bug report (issue
>> >> 385).
>> >
>> > Second bad message of the day: I do not remember where this fix is. Can
>> > you just apply to 4msysgit.git's master, please?
>>
>> I think Sebastian means this one:
>>
>>     From: Sebastian Schuberth <sschu...@gmail.com>
>>     Subject: Re: [PATCH] If deriving SVN_SSH from GIT_SSH on msys, also add quotes
>>     Date: Sat, 23 Jan 2010 15:20:28 +0100
>>     Message-ID: <4B5B05AC...@gmail.com>
>>
>> (aka $gmane/137841).
>>
>> I'll queue it myself (Eric Cc'ed) before 1.7.0-rc1.
>
> Thanks, I also applied it to 4msysgit.git.

Yes, that's the fix I meant, thanks.

--
Sebastian Schuberth

[Sebastian Schuberth]

On Sat, Jan 30, 2010 at 03:37, Johannes Schindelin
<Johannes....@gmx.de> wrote:

> Hi,
>
> first bad message of the day: I did not manage to find any Git time
> yesterday (Friday).
>
> On Thu, 28 Jan 2010, Sebastian Schuberth wrote:
>
>> Yes, I'd like to get ss/installer-improvements merged, and if I don't
>> manage to incorporate Heiko's changes, probably merge his
>> hv/cheetah-installer first.

My bad message of the day is that I did not manage to finish
ss/installer-improvements yesterday, although I think it's coming
along quite nicely. I just pushed the current WIP state for those who
are interested.

I'm now having some issues with git-cheetah which prevent me from
testing the installer. I'll try to resolve them, probably together
with Heiko.

--
Sebastian Schuberth

[Johannes Sixt]

I thought I said something. It works for me as intended. I was using it for
quite some time. You have my ACK.

BTW, I noticed a considerable size reduction of the msys dll. Is it because it
is compiled with a new compiler?

-- Hannes

PS: I'll be offline for the rest of the weekend.

[Johannes Schindelin]

Hi,

On Sat, 30 Jan 2010, Johannes Sixt wrote:

> On Samstag, 30. Januar 2010, Johannes Schindelin wrote:
> > Hannes,
> >
> > I just remembered that I pushed out the 'no-fstab-thread' branch for
> > you, but you never came back to me (or I missed the reply). What about
> > it? Should I merge?
>
> I thought I said something. It works for me as intended. I was using it
> for quite some time. You have my ACK.

Thanks. Merged and pushed.

> BTW, I noticed a considerable size reduction of the msys dll. Is it
> because it is compiled with a new compiler?

No, I still used the old MSys compiler.

> PS: I'll be offline for the rest of the weekend.

Have fun!

Ciao,
Dscho

[Johannes Schindelin]

Hi,

Good!

Ciao,
Dscho

[Heiko Voigt]

Hi,

On Sat, Jan 30, 2010 at 03:37:49AM +0100, Johannes Schindelin wrote:
> So I will rely on you guys to run the test suite and find bugs and fix
> them, because I just take too long.

No problem. Just announce when you have something and I'll gladly run
the testsuite.

cheers Heiko

[Johannes Schindelin]

Hi,

Thanks, I want to take up on this offer.

Because, I give up for this weekend. I merged mingw.git/master into devel,
and now, running t7002 segfaults (it was _not_ the recent msys-1.0.dll
patch, as I suspected first, sorry for that).

Due to the recent tweaks in the testsuite, debugging got _much_ more
fiddly. I really had to edit bin-wrappers (any idea why this is _not_ in
t/, anyone?), so that the "git" script checks for an environment variable
"USEGDB" and executes "gdb --args [...]" instead if that variable has a
non-empty value. Then I edited t7002 to call "git grep [...] -w [...]"
with that variable set to 1.

Unfortunately, the stdout in this case is sent to _somewhere_ so that I
had to control the gdb blindly. Basically, I typed "r<RET>" to run,
"bt<RET>" for the backtrace, and then "q<RET>y<RET>" to quit the debugger,
which finally sent the output to the console, including the commands I
typed:

> Starting program: C:/msysgit/git/git.exe grep -n -w -e mmap HEAD
> [New thread 1172.0x430]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
> from C:\WINDOWS\system32\ntdll.dll
> (gdb) bt
> #0 0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
> from C:\WINDOWS\system32\ntdll.dll
> #1 0x7c90104b in ntdll!RtlEnumerateGenericTableLikeADirectory ()
> from C:\WINDOWS\system32\ntdll.dll
> #2 0x0050ba88 in grep_mutex ()
> #3 0x00425aa3 in load_sha1 (sha1=0x0, size=0x50ba98,
> name=0x7e8 <Address 0x7e8 out of bounds>) at builtin-grep.c:417
> #4 0x004264be in grep_sha1 (opt=0x22fd84, sha1=<value optimized out>,
> filename=0x810cb0 "HEAD:file", tree_name_len=5) at builtin-grep.c:452
> #5 0x004266cb in grep_tree (opt=0x22fd84, paths=<value optimized out>,
> tree=<value optimized out>, tree_name=0x3e25e9 "HEAD",
> base=<value optimized out>) at builtin-grep.c:601
> #6 0x00427640 in cmd_grep (argc=6, argv=0x3e26ec, prefix=0x0)
> at builtin-grep.c:641
> #7 0x0040187e in handle_internal_command (argc=<value optimized out>,
> argv=<value optimized out>) at git.c:257
> #8 0x00401a93 in main (argc=7, argv=0x3e26e8) at git.c:454

As you can see, the fault is in the new threaded grep.

It may be easier to debug if the programs are recompiled _without_ -O2
(however, recompiling takes about 30 minutes in my virtual machine, and I
desperately need sleep).

Can you please investigate further?

Thanks,
Dscho

[Johannes Schindelin]

Hi,

Just to make sure: this patch made it into 1.7.0, right?

Thanks,
Dscho

[Pat Thoyts]

On 14 February 2010 02:16, Johannes Schindelin

Looks to me like it was merged in just before 1.7.0rc2 (id c80d7be) so yes.

Pat Thoyts.

[Johannes Sixt]

Johannes Schindelin schrieb:

>> Starting program: C:/msysgit/git/git.exe grep -n -w -e mmap HEAD
>> [New thread 1172.0x430]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
>> from C:\WINDOWS\system32\ntdll.dll
>> (gdb) bt
>> #0 0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
>> from C:\WINDOWS\system32\ntdll.dll
>> #1 0x7c90104b in ntdll!RtlEnumerateGenericTableLikeADirectory ()
>> from C:\WINDOWS\system32\ntdll.dll
>> #2 0x0050ba88 in grep_mutex ()
>> #3 0x00425aa3 in load_sha1 (sha1=0x0, size=0x50ba98,
>> name=0x7e8 <Address 0x7e8 out of bounds>) at builtin-grep.c:417
>> #4 0x004264be in grep_sha1 (opt=0x22fd84, sha1=<value optimized out>,
>> filename=0x810cb0 "HEAD:file", tree_name_len=5) at builtin-grep.c:452
>> #5 0x004266cb in grep_tree (opt=0x22fd84, paths=<value optimized out>,
>> tree=<value optimized out>, tree_name=0x3e25e9 "HEAD",
>> base=<value optimized out>) at builtin-grep.c:601
>> #6 0x00427640 in cmd_grep (argc=6, argv=0x3e26ec, prefix=0x0)
>> at builtin-grep.c:641
>> #7 0x0040187e in handle_internal_command (argc=<value optimized out>,
>> argv=<value optimized out>) at git.c:257
>> #8 0x00401a93 in main (argc=7, argv=0x3e26e8) at git.c:454
>
> As you can see, the fault is in the new threaded grep.

I don't observe this crash with mingw.git nor mingw/j6t.git, neither with
-O0 nor -O2. I'm using msysgit's devel with the recent msys dll changes so
that the grep '*' test does not have to be skipped.

I have only one box to test on, currently, which is a rather beefy one.
The backtrace looks like it happens in the contended case of a mutex (i.e.
on thread is indeed waiting for it), and on a fast machine like mine this
contention perhaps doesn't happen.

-- Hannes

[Erik Faye-Lund]

On Sun, Feb 14, 2010 at 3:13 AM, Johannes Schindelin
<Johannes....@gmx.de> wrote:
>> Starting program: C:/msysgit/git/git.exe grep -n -w -e mmap HEAD
>> [New thread 1172.0x430]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> (gdb) bt
>> #0  0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> #1  0x7c90104b in ntdll!RtlEnumerateGenericTableLikeADirectory ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> #2  0x0050ba88 in grep_mutex ()
>> #3  0x00425aa3 in load_sha1 (sha1=0x0, size=0x50ba98,
>>     name=0x7e8 <Address 0x7e8 out of bounds>) at builtin-grep.c:417

Humm. Is it just me that finds sha1=NULL to be very sketchy? I tried
to trace downwards in the code-path a bit, and it didn't look like
read_sha1_file expected sha1 to be NULL. Or is this one of the cases
where the debugger fools me? I see the next couple of lines from the
stack-trace has sha1 as <value optimized out>...

>> #4  0x004264be in grep_sha1 (opt=0x22fd84, sha1=<value optimized out>,
>>     filename=0x810cb0 "HEAD:file", tree_name_len=5) at builtin-grep.c:452
>> #5  0x004266cb in grep_tree (opt=0x22fd84, paths=<value optimized out>,
>>     tree=<value optimized out>, tree_name=0x3e25e9 "HEAD",
>>     base=<value optimized out>) at builtin-grep.c:601
>> #6  0x00427640 in cmd_grep (argc=6, argv=0x3e26ec, prefix=0x0)
>>     at builtin-grep.c:641
>> #7  0x0040187e in handle_internal_command (argc=<value optimized out>,
>>     argv=<value optimized out>) at git.c:257
>> #8  0x00401a93 in main (argc=7, argv=0x3e26e8) at git.c:454
>
> As you can see, the fault is in the new threaded grep.
>
> It may be easier to debug if the programs are recompiled _without_ -O2
> (however, recompiling takes about 30 minutes in my virtual machine, and I
> desperately need sleep).
>
> Can you please investigate further?
>
> Thanks,
> Dscho
>
>

--
Erik "kusma" Faye-Lund

[Johannes Schindelin]

Hi,

On Sun, 14 Feb 2010, Erik Faye-Lund wrote:

> On Sun, Feb 14, 2010 at 3:13 AM, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
> >> Starting program: C:/msysgit/git/git.exe grep -n -w -e mmap HEAD
> >> [New thread 1172.0x430]
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
> >> � �from C:\WINDOWS\system32\ntdll.dll
> >> (gdb) bt
> >> #0 �0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
> >> � �from C:\WINDOWS\system32\ntdll.dll
> >> #1 �0x7c90104b in ntdll!RtlEnumerateGenericTableLikeADirectory ()
> >> � �from C:\WINDOWS\system32\ntdll.dll
> >> #2 �0x0050ba88 in grep_mutex ()
> >> #3 �0x00425aa3 in load_sha1 (sha1=0x0, size=0x50ba98,
> >> � � name=0x7e8 <Address 0x7e8 out of bounds>) at builtin-grep.c:417
>
> Humm. Is it just me that finds sha1=NULL to be very sketchy?

As I said: it is probably an issue of a code compiled with -O2. That is
why I asked all of you for your help.

> I tried to trace downwards in the code-path a bit, and it didn't look
> like read_sha1_file expected sha1 to be NULL. Or is this one of the
> cases where the debugger fools me? I see the next couple of lines from
> the stack-trace has sha1 as <value optimized out>...
>
> >> #4 �0x004264be in grep_sha1 (opt=0x22fd84, sha1=<value optimized out>,
> >> � � filename=0x810cb0 "HEAD:file", tree_name_len=5) at builtin-grep.c:452
> >> #5 �0x004266cb in grep_tree (opt=0x22fd84, paths=<value optimized out>,
> >> � � tree=<value optimized out>, tree_name=0x3e25e9 "HEAD",
> >> � � base=<value optimized out>) at builtin-grep.c:601
> >> #6 �0x00427640 in cmd_grep (argc=6, argv=0x3e26ec, prefix=0x0)
> >> � � at builtin-grep.c:641
> >> #7 �0x0040187e in handle_internal_command (argc=<value optimized out>,
> >> � � argv=<value optimized out>) at git.c:257
> >> #8 �0x00401a93 in main (argc=7, argv=0x3e26e8) at git.c:454
> >
> > As you can see, the fault is in the new threaded grep.
> >
> > It may be easier to debug if the programs are recompiled _without_ -O2
> > (however, recompiling takes about 30 minutes in my virtual machine, and I
> > desperately need sleep).
> >
> > Can you please investigate further?
> >
> > Thanks,
> > Dscho
> >
> >

BTW there is no law passed in any of the states I know that you have to
quote stuff that you are _not_ responding to.

In fact, those parts come out pretty bad in a global time balance: it
takes roughly the same time to delete them as to read them. So if, say,
500 people read them, you failed to save 500 times the time you saved
_personally_, to _others_. As a consequence, at least _I_ am less likely
to read your mails in a timely manner, or at all, because I am _short on
time already_.

Ciao,
Dscho

[Johannes Schindelin]

Hi,

It could very well be a timing-related issue. FWIW I am compiling in a
QEmu instance on a pretty beefy machine, which means that it is not
_totally_ slow (compilation takes 30 minutes, not _hours_), but it is an
inherently-single-core system.

What I mean to say is: could somebody with a _less_ beefy (but
non-virtual) machine try and reproduce my problems?

If there are no problems with _real_ systems, I will no longer believe
that there is an issue and release Git for Windows (even if people like
thecybershadow benefit from that, but that is just secondary).

Ciao,
Dscho

[Christian MICHON]

On Sun, Feb 14, 2010 at 8:17 PM, Johannes Schindelin
<Johannes....@gmx.de> wrote:
> It could very well be a timing-related issue. FWIW I am compiling in a
> QEmu instance on a pretty beefy machine, which means that it is not
> _totally_ slow (compilation takes 30 minutes, not _hours_), but it is an
> inherently-single-core system.
>
> What I mean to say is: could somebody with a _less_ beefy (but
> non-virtual) machine try and reproduce my problems?

yes I can. I'll look again at this thread to see what you're looking for.

>
> If there are no problems with _real_ systems, I will no longer believe
> that there is an issue and release Git for Windows (even if people like
> thecybershadow benefit from that, but that is just secondary).

--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !

[Johannes Schindelin]

Hi,

On Sun, 14 Feb 2010, Christian MICHON wrote:

> On Sun, Feb 14, 2010 at 8:17 PM, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
> > It could very well be a timing-related issue. FWIW I am compiling in a
> > QEmu instance on a pretty beefy machine, which means that it is not
> > _totally_ slow (compilation takes 30 minutes, not _hours_), but it is
> > an inherently-single-core system.
> >
> > What I mean to say is: could somebody with a _less_ beefy (but
> > non-virtual) machine try and reproduce my problems?
>
> yes I can. I'll look again at this thread to see what you're looking
> for.

To save you time: please pull 'devel' in an msysGit's /git/, compile, and
run the t7002 test.

Thanks,
Dscho

[Christian MICHON]

On Sun, Feb 14, 2010 at 8:29 PM, Johannes Schindelin
<Johannes....@gmx.de> wrote:
> To save you time: please pull 'devel' in an msysGit's /git/, compile, and
> run the t7002 test.
>

not sure if my workflow is the right one (I sent you a private email
about it, just to confirm).

after pulling devel for both msysgit and 4msysgit, I get this when
running /git/t/t7002-grep.sh

Xian@HPMAILS /git/t (master)
$ ./t7002-grep.sh
* ok 1: setup
* ok 2: grep should not segfault with a bad input
* ok 3: grep -w HEAD
* ok 4: grep -w HEAD (w)
* ok 5: grep -w HEAD (x)
* ok 6: grep -w HEAD (y-1)
* ok 7: grep -w HEAD (y-2)
* ok 8: grep -w HEAD (z)
* ok 9: grep HEAD (t-1)
* ok 10: grep HEAD (t-2)
* ok 11: grep HEAD (t-3)
* ok 12: grep -c HEAD (no /dev/null)
* ok 13: grep --max-depth -1 HEAD
* ok 14: grep --max-depth 0 HEAD
* FAIL 15: grep --max-depth 0 -- '*' HEAD

{
echo ${HC}t/a/v:1:vvv
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- "*" >actual &&
test_cmp expected actual

* ok 16: grep --max-depth 1 HEAD
* ok 17: grep --max-depth 0 -- t HEAD
* ok 18: grep -w in working tree
* ok 19: grep -w in working tree (w)
* ok 20: grep -w in working tree (x)
* ok 21: grep -w in working tree (y-1)
* ok 22: grep -w in working tree (y-2)
* ok 23: grep -w in working tree (z)
* ok 24: grep in working tree (t-1)
* ok 25: grep in working tree (t-2)
* ok 26: grep in working tree (t-3)
* ok 27: grep -c in working tree (no /dev/null)
* ok 28: grep --max-depth -1 in working tree
* ok 29: grep --max-depth 0 in working tree
* FAIL 30: grep --max-depth 0 -- '*' in working tree

{
echo ${HC}t/a/v:1:vvv
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- "*" >actual &&
test_cmp expected actual

* ok 31: grep --max-depth 1 in working tree
* ok 32: grep --max-depth 0 -- t in working tree
* ok 33: grep -e A --and -e B
* ok 34: grep ( -e A --or -e B ) --and -e B
* ok 35: grep -e A --and --not -e B
* ok 36: grep -f, non-existent file
* ok 37: grep -f, one pattern
* ok 38: grep -f, multiple patterns
* ok 39: grep -f, ignore empty lines
* ok 40: grep -C1, hunk mark between files
* ok 41: grep -C1 --no-ext-grep, hunk mark between files
* ok 42: log grep setup
* ok 43: log grep (1)
* ok 44: log grep (2)
* ok 45: log grep (3)
* ok 46: log grep (4)
* ok 47: log grep (5)
* ok 48: log grep (6)
* ok 49: grep with CE_VALID file
* ok 50: grep -p with userdiff
* ok 51: grep -p
* ok 52: grep -p -B5
* ok 53: grep from a subdirectory to search wider area (1)
* ok 54: grep from a subdirectory to search wider area (2)
* failed 2 among 54 test(s)

[Pat Thoyts]

I ran the share/msysGit/run-tests.sh script and it appears to have
hung after doing t9301-fast-import-notes.sh.

The following files had failures on this Windows 7 x64 box. The
failing test numbers are appended except for the gitweb ones where
everything fails.

t1300-repo-config.sh: 70, 71
t5000-tar-tree.sh: 12
t5530-upload-pack-error.sh: 6
t5560-http-backend-noserver.sh: 2,3,4,5,6,7,8,9,10,11,12,13
t7002-grep.sh: 15, 30
t7602-merge-octopus-many.sh: 3,4,5
t9001-send-email.sh: 8, 10, 12,
t9500-gitweb-standalone-no-errors.sh: (nearly all)
t9501-gitweb-standalone-http-status.sh: 1-10 (all)
t9502-gitweb-standalone-parse-output.sh: 2-10

What I do _not_ see is a segfault from any of these tests.

t1300.70 and t1300.71 are I think just minor rename issues. The test
looks for '/dev/null' but the result is 'nul' and path.home is
returning a Windows native path where the test is looking for an msys
style path (/c/Users/pat in my case). These should probably be skipped
for msysgit unless we have a system for alternating tests for
different platforms.

I dont know enough to rate these in significance but the t7602 and
t5530 seem like they might be problems. The gitweb tests don't seem
relevant for msysgit.

Pat Thoyts

[Christian MICHON]

On Mon, Feb 15, 2010 at 1:38 AM, Pat Thoyts <patt...@googlemail.com> wrote:
> I ran the share/msysGit/run-tests.sh script and it appears to have
> hung after doing t9301-fast-import-notes.sh.

Mine hung on this one:
Unfinished tests: t9200-git-cvsexportcommit

>
> The following files had failures on this Windows 7 x64 box. The
> failing test numbers are appended except for the gitweb ones where
> everything fails.
>
> t1300-repo-config.sh: 70, 71
> t5000-tar-tree.sh: 12
> t5530-upload-pack-error.sh: 6
> t5560-http-backend-noserver.sh: 2,3,4,5,6,7,8,9,10,11,12,13
> t7002-grep.sh: 15, 30
> t7602-merge-octopus-many.sh: 3,4,5
> t9001-send-email.sh: 8, 10, 12,
> t9500-gitweb-standalone-no-errors.sh: (nearly all)
> t9501-gitweb-standalone-http-status.sh:  1-10 (all)
> t9502-gitweb-standalone-parse-output.sh: 2-10

I'll double check in detail with my vista results tomorrow :-)

I've not gone down to the exact fail numbers, but here is the list of
failed test:
t1300-repo-config.sh failed
t4201-shortlog.sh failed
t5000-tar-tree.sh failed
t5516-fetch-push.sh failed
t5530-upload-pack-error.sh failed
t5560-http-backend-noserver.sh failed
t5601-clone.sh failed
t7002-grep.sh failed
t7602-merge-octopus-many.sh failed
t9001-send-email.sh failed
t9500-gitweb-standalone-no-errors.sh failed
t9501-gitweb-standalone-http-status.sh failed
t9502-gitweb-standalone-parse-output.sh failed

>
> What I do _not_ see is a segfault from any of these tests.

same here: no segfault.

>
> t1300.70 and t1300.71 are I think just minor rename issues. The test
> looks for '/dev/null' but the result is 'nul' and path.home is
> returning a Windows native path where the test is looking for an msys
> style path (/c/Users/pat in my case). These should probably be skipped
> for msysgit unless we have a system for alternating tests for
> different platforms.
>
> I dont know enough to rate these in significance but the t7602 and
> t5530 seem like they might be problems. The gitweb tests don't seem
> relevant for msysgit.
>

well actually I've been quite successful lately at using Mongoose as a
small gitweb server on windows xp. So I believe there's some relevance
now here, at least.

I should put somewhere the exact details for this to work. It's
actually quite fun to manage gitweb on windows. Thanks Alexandrul for
the pointers on Mongoose.

[Johannes Schindelin]

Hi,

On Mon, 15 Feb 2010, Pat Thoyts wrote:

> I ran the share/msysGit/run-tests.sh script and it appears to have hung
> after doing t9301-fast-import-notes.sh.
>
> The following files had failures on this Windows 7 x64 box. The failing
> test numbers are appended except for the gitweb ones where everything
> fails.
>
> t1300-repo-config.sh: 70, 71
> t5000-tar-tree.sh: 12
> t5530-upload-pack-error.sh: 6
> t5560-http-backend-noserver.sh: 2,3,4,5,6,7,8,9,10,11,12,13
> t7002-grep.sh: 15, 30
> t7602-merge-octopus-many.sh: 3,4,5
> t9001-send-email.sh: 8, 10, 12,
> t9500-gitweb-standalone-no-errors.sh: (nearly all)
> t9501-gitweb-standalone-http-status.sh: 1-10 (all)
> t9502-gitweb-standalone-parse-output.sh: 2-10
>
> What I do _not_ see is a segfault from any of these tests.

Great!

OTOH it is also a bit sad, because it means that I no longer have any
means to test Git for Windows properly.

> t1300.70 and t1300.71 are I think just minor rename issues. The test
> looks for '/dev/null' but the result is 'nul' and path.home is
> returning a Windows native path where the test is looking for an msys
> style path (/c/Users/pat in my case). These should probably be skipped
> for msysgit unless we have a system for alternating tests for
> different platforms.

Indeed.

> I dont know enough to rate these in significance but the t7602 and t5530
> seem like they might be problems. The gitweb tests don't seem relevant
> for msysgit.

I concur. The t5530 issue probably means that we cannot detect failures
from subprocesses correctly, but t7602 is much less worrisome: it just
means that the pretty-printing of branch names does not work as intended.

Of course, I would like to have these issues fixed nevertheless, but I do
not want to hold off longer with a Git for Windows release.

Thanks for testing!
Dscho

[Johannes Schindelin]

Hey Heiko & Sebastian,

what's the status on Git-Cheetah integration into the Git for Windows
installer?

Other than that, there is nothing holding me back from making a new
release.

Ciao,
Dscho

[Heiko Voigt]

On Mon, Feb 15, 2010 at 07:38:12PM +0100, Johannes Schindelin wrote:
> Hey Heiko & Sebastian,
>
> what's the status on Git-Cheetah integration into the Git for Windows
> installer?

The integration is ready as far as cheetah is concerned. Not sure about
Sebastians branch the last I know is that its still WIP.

One issue with my branch though: We have no cheetah for Windows 64bit.
The current registry based context menu entries are more platform
independent and should also work there. So if you decide to merge that
branch they do not have a context menu anymore.

So maybe that could result in more issue spam. I would leave the
decision to you...

cheers Heiko

[Johannes Sixt]

Johannes Schindelin schrieb:
>> t7002-grep.sh: 15, 30

Christian, Pat, if you update your msysgit environment to devel, then
these two tests pass.

Dscho, the segfaults that you observe don't happen to be in one of these
two tests?

> The t5530 issue probably means that we cannot detect failures
> from subprocesses correctly,

I've a patch that passes this test in my private tree, but it is
definitely post-1.7.0 material. (In fact, I had a hack to this end since
years, but now I have a real fix.)

-- Hannes

[Johannes Schindelin]

Hi,

On Mon, 15 Feb 2010, Johannes Sixt wrote:

> Johannes Schindelin schrieb:
> > > t7002-grep.sh: 15, 30
>
> Christian, Pat, if you update your msysgit environment to devel, then
> these two tests pass.
>
> Dscho, the segfaults that you observe don't happen to be in one of these
> two tests?

I made extra sure that those issues were happening on a then-current
'devel/devel'.

Testing again, with a now-current 'devel/devel'. Which takes. a. ges.

> > The t5530 issue probably means that we cannot detect failures from
> > subprocesses correctly,
>
> I've a patch that passes this test in my private tree, but it is
> definitely post-1.7.0 material. (In fact, I had a hack to this end since
> years, but now I have a real fix.)

Okay, I do not have a problem doing a release now -- read: tomorrow --
with those issues. (Without git-cheetah for the moment, as 64-bit is
unhandled otherwise, as pointed out by Heiko.)

Ciao,
Dscho

[Johannes Schindelin]

Hi,

On Mon, 15 Feb 2010, Johannes Sixt wrote:

> Johannes Schindelin schrieb:
> > > t7002-grep.sh: 15, 30
>
> Christian, Pat, if you update your msysgit environment to devel, then
> these two tests pass.
>
> Dscho, the segfaults that you observe don't happen to be in one of these
> two tests?

No, they do not happen in 15 or 30, but in 3!

And I think I sent out a backtrace pointing to the recent threading
enhancements as the culprit.

<clicketyclick> Indeed:

http://article.gmane.org/gmane.comp.version-control.msysgit/8669

Ciao,
Dscho

[Pat Thoyts]

On 15 February 2010 20:35, Johannes Schindelin

<Johannes....@gmx.de> wrote:
> Hi,
>
> On Mon, 15 Feb 2010, Johannes Sixt wrote:
>
>> Johannes Schindelin schrieb:
>> > > t7002-grep.sh: 15, 30
>>
>> Christian, Pat, if you update your msysgit environment to devel, then
>> these two tests pass.
>>
>> Dscho, the segfaults that you observe don't happen to be in one of these
>> two tests?
>
> I made extra sure that those issues were happening on a then-current
> 'devel/devel'.
>

As far as I can tell I'm testing devel.
I checked out devel in / and in /git, built git and then called the
runtests script.
ie:
cd / && git checkout devel
cd /git && git checkout devel
make prefix=/ all
/share/msysGit/run-tests.sh

When running the individual tests I did:
cd t && ./7002-grep.sh

If there is something else to be done here - let me know and we can
update the wiki notes.

[Heiko Voigt]

I think I got the culprit. It should be apparent even on other platforms
(in case pthread does not require init maybe not). It seems everyone has
multicore systems now...

> 880 if (online_cpus() == 1 || !grep_threads_ok(&opt))
> (gdb) n
> 881 use_threads = 0;
> (gdb) n
> 883 if (use_threads)
> (gdb) n

and now have a look at the code there:

> #ifndef NO_PTHREADS
> if (online_cpus() == 1 || !grep_threads_ok(&opt))
> use_threads = 0;
>
> if (use_threads)
> start_threads(&opt);
> #else

in our case (Dscho's and mine) with one cpu start_threads never gets called and
look whats happening right in the beginning of this function:

> static void start_threads(struct grep_opt *opt)
> {
> int i;
>
> pthread_mutex_init(&grep_mutex, NULL);
> pthread_mutex_init(&read_sha1_mutex, NULL);
> pthread_cond_init(&cond_add, NULL);
> pthread_cond_init(&cond_write, NULL);
> pthread_cond_init(&cond_result, NULL);
> ...

well... this fixes the testcase:

---8<-----
From 4e455b99876cdedf8928d112b0b2e2e4e8158066 Mon Sep 17 00:00:00 2001
From: Heiko Voigt <hvo...@hvoigt.net>
Date: Mon, 15 Feb 2010 22:26:42 +0100
Subject: [PATCH] fix threaded grep for machines with only one cpu

In case the machine has only one cpu the mutex initialization was
skipped.

Signed-off-by: Heiko Voigt <hvo...@hvoigt.net>
---
Not sure if we need pthread_cond_init but I thought initializing them as well
was not a bad idea.

builtin-grep.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/builtin-grep.c b/builtin-grep.c
index 26d4deb..644051c 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -220,12 +220,6 @@ static void start_threads(struct grep_opt *opt)
{
int i;

- pthread_mutex_init(&grep_mutex, NULL);
- pthread_mutex_init(&read_sha1_mutex, NULL);
- pthread_cond_init(&cond_add, NULL);
- pthread_cond_init(&cond_write, NULL);
- pthread_cond_init(&cond_result, NULL);
-
for (i = 0; i < ARRAY_SIZE(todo); i++) {
strbuf_init(&todo[i].out, 0);
}
@@ -880,6 +874,12 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (online_cpus() == 1 || !grep_threads_ok(&opt))
use_threads = 0;

+ pthread_mutex_init(&grep_mutex, NULL);
+ pthread_mutex_init(&read_sha1_mutex, NULL);
+ pthread_cond_init(&cond_add, NULL);
+ pthread_cond_init(&cond_write, NULL);
+ pthread_cond_init(&cond_result, NULL);
+
if (use_threads)
start_threads(&opt);
#else
--
1.7.0.rc1.7.gc0da5

[Johannes Schindelin]

Hi,

On Mon, 15 Feb 2010, Pat Thoyts wrote:

> On 15 February 2010 20:35, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
>
> > On Mon, 15 Feb 2010, Johannes Sixt wrote:
> >
> >> Johannes Schindelin schrieb:
> >> > > t7002-grep.sh: 15, 30
> >>
> >> Christian, Pat, if you update your msysgit environment to devel, then
> >> these two tests pass.
> >>
> >> Dscho, the segfaults that you observe don't happen to be in one of
> >> these two tests?
> >
> > I made extra sure that those issues were happening on a then-current
> > 'devel/devel'.
> >
> As far as I can tell I'm testing devel.
> I checked out devel in / and in /git, built git and then called the
> runtests script.
> ie:
> cd / && git checkout devel
> cd /git && git checkout devel

You might want to check with "git status" that you do not have any
uncommitted changes, and with "git log origin/devel.." that you do not
have any unpushed changes.

> make prefix=/ all

Just "make" is enough.

> /share/msysGit/run-tests.sh
>
> When running the individual tests I did:
> cd t && ./7002-grep.sh
>
> If there is something else to be done here - let me know and we can
> update the wiki notes.

Funny you should say that: today, I updated the descriptions on the Wiki
pages for Christian Michon:

http://code.google.com/p/msysgit/source/detail?r=79

(In case you wondered how to get there: On the "Project Home" tab, just
under the tab title, you will find an innocuous "Updates" link, which is
really informative.)

Ciao,
Dscho

[Sebastian Schuberth]

On Mon, Feb 15, 2010 at 20:41, Heiko Voigt <hvo...@hvoigt.net> wrote:

> On Mon, Feb 15, 2010 at 07:38:12PM +0100, Johannes Schindelin wrote:
>> Hey Heiko & Sebastian,
>>
>> what's the status on Git-Cheetah integration into the Git for Windows
>> installer?
>
> The integration is ready as far as cheetah is concerned. Not sure about
> Sebastians branch the last I know is that its still WIP.

Yeah, due to a lack of motivation I didn't do much there in the last
weeks, sorry.

> One issue with my branch though: We have no cheetah for Windows 64bit.
> The current registry based context menu entries are more platform
> independent and should also work there. So if you decide to merge that
> branch they do not have a context menu anymore.

In my branch, I left the registry-based context menus entries in the
installer, but introduced an either-or relationship with Cheetah. I
believe that's the way we should go, even if we had Cheetah for
64-bit.

Now that the installer is the only thing holding back a release, I'll
try to finish my branch tomorrow or the day after that at the latest.
If I don't manage to do that, we should merge Heiko's branch and a
modified version of my branch instead.

--
Sebastian Schuberth

[Johannes Schindelin]

Hi,

Heiko, you are my hero. Officially.

I applied your patch and it definitely fixed the issue. Oh, and you proved
that I was right, and Linus was wrong, when I claimed that it is a bad
thing for developers to have a substantially different setup (read:
beefier) from the users.

Do you want to push this to Junio, or should I do that?

Ciao,
Dscho

[Johannes Schindelin]

Hi,

On Mon, 15 Feb 2010, Sebastian Schuberth wrote:

> On Mon, Feb 15, 2010 at 20:41, Heiko Voigt <hvo...@hvoigt.net> wrote:
>
> > On Mon, Feb 15, 2010 at 07:38:12PM +0100, Johannes Schindelin wrote:
> >> Hey Heiko & Sebastian,
> >>
> >> what's the status on Git-Cheetah integration into the Git for Windows
> >> installer?
> >
> > The integration is ready as far as cheetah is concerned. Not sure
> > about Sebastians branch the last I know is that its still WIP.
>
> Yeah, due to a lack of motivation I didn't do much there in the last
> weeks, sorry.

No need to be sorry. I hope I was not the reason for that lack of
motivation, though...

> > One issue with my branch though: We have no cheetah for Windows 64bit.
> > The current registry based context menu entries are more platform
> > independent and should also work there. So if you decide to merge that
> > branch they do not have a context menu anymore.
>
> In my branch, I left the registry-based context menus entries in the
> installer, but introduced an either-or relationship with Cheetah. I
> believe that's the way we should go, even if we had Cheetah for
> 64-bit.

Yes, that sounds optimal. This switch could be suppressed on 64-bit
machines for the moment (read: until we integrate mingw-w64 cross
compilers into the system and make use of them).

> Now that the installer is the only thing holding back a release, I'll
> try to finish my branch tomorrow or the day after that at the latest. If
> I don't manage to do that, we should merge Heiko's branch and a modified
> version of my branch instead.

Okay.

I might apply one or two goodies from my personal branch to 4msysgit.git
in the meantime.

Ciao,
Dscho

[Sebastian Schuberth]

On Mon, Feb 15, 2010 at 23:44, Johannes Schindelin
<Johannes....@gmx.de> wrote:

>> > The integration is ready as far as cheetah is concerned. Not sure
>> > about Sebastians branch the last I know is that its still WIP.
>>
>> Yeah, due to a lack of motivation I didn't do much there in the last
>> weeks, sorry.
>
> No need to be sorry. I hope I was not the reason for that lack of
> motivation, though...

Not at all. It's just that msysGit works very well for me, and I feel
like I'm just scratching other people's itches when working on it
these days. That would be OK if I would get paid for it, but as you
all, too, I don't :-) I guess you know all to well what I'm talking
about, Dscho.

--
Sebastian Schuberth

[Heiko Voigt]

On Mon, Feb 15, 2010 at 11:39:19PM +0100, Johannes Schindelin wrote:
> Heiko, you are my hero. Officially.

Thank you very much, such a compliment is very much appreciated.

> I applied your patch and it definitely fixed the issue. Oh, and you proved
> that I was right, and Linus was wrong, when I claimed that it is a bad
> thing for developers to have a substantially different setup (read:
> beefier) from the users.
>
> Do you want to push this to Junio, or should I do that?

I just sent out the patch to Junio.

cheers Heiko

[Johannes Schindelin]

Hi,

On Mon, 15 Feb 2010, Sebastian Schuberth wrote:

Yes, I know. Although in this case, I have been asked to make a new
release by someone who already gave me nice code (although not Git code).
So _I_ do get something in return.

In related news, I recently talked to somebody who wants to use Git for
Windows in a big company, and I suggested that there are several things a
company can do to show their appreciation, and maybe even motivate more
unpaid work:

- rdesktop access to a fast Windows computer where I can compile & test
msysGit on,

- a sponsored hackathon, i.e. a meeting where certain Git hackers are
invited, food, accomodation & travel are paid for, and the only thing
they have to do is to have fun coding Git. I would have a favorite list
of people for that already.

- a beer with you (possibly after giving a talk about something Git
related to your bunch of developers, but not in French, je ne parle pas
francais assez bon pour ca, et je manque les accents sur mon clavier ;-)

Just in case some benefitting party rightfully thinks they should
contribute back something.

Ciao,
Dscho

[Heiko Voigt]

On Mon, Feb 15, 2010 at 09:20:08PM +0000, Pat Thoyts wrote:
> On 15 February 2010 20:35, Johannes Schindelin
> <Johannes....@gmx.de> wrote:
> > Hi,
> >
> > On Mon, 15 Feb 2010, Johannes Sixt wrote:
> >
> >> Johannes Schindelin schrieb:
> >> > > t7002-grep.sh: 15, 30
> >>
> >> Christian, Pat, if you update your msysgit environment to devel, then
> >> these two tests pass.
> >>
> >> Dscho, the segfaults that you observe don't happen to be in one of these
> >> two tests?
> >
> > I made extra sure that those issues were happening on a then-current
> > 'devel/devel'.
> >
> As far as I can tell I'm testing devel.
> I checked out devel in / and in /git, built git and then called the
> runtests script.
> ie:
> cd / && git checkout devel
> cd /git && git checkout devel
> make prefix=/ all
> /share/msysGit/run-tests.sh

I just observed the same tests failing with the current msys-1.0.dll in
devel. This was on a machine with 2 cores. I ran the same test here on
my virtual one core machine and it passes. Seems we have some race
condition here. I did not investigate further today but just so you know
that this indeed seems to be another one cpu against 2 cpu bug.

cheers Heiko

[Heiko Voigt]

Further investigations shows that it actually does not seem to be any
threading issue. I ran the test on Windows XP on the same machine and it
passed. In my previous post the same was done on Windows 7. So it seems
to be an issue on newer Windows versions than XP.

I will try to have a look at the msys source and figure out why it
behaves differently on Windows 7. Not sure when I will find time to
debug though because debugging msys is not something you can do in
between and I do not have access to that machine in my free time.

cheers Heiko

[Johannes Schindelin]

Hi,

Hmpf. Oh well, then the upcoming Git for Windows installer will be XP
only.

<sarcasm>
Maybe this will teach the companies who use Git for Windows without even
so much as contributing a patch that it might be a clever idea to treat
the developers who do the real work to something nice, such as a mega-fast
Windows 7 computer.
</sarcasm>

Ciao,
Dscho