>> On 27 February 2012 11:16, David C. Rankin
>> <drankinatty@...>wrote:
>>
>>> On 02/24/2012 06:55 PM, Jay wrote:
>>> > If this is the case you could perhaps try downgrading git. I have
>>> seen
>>> this
>>> > problem with newer git. Also if https is supported, try it.
>>> >
>>> > Jay
>>>
>>> Hmm..., how can we have a GIT server that doesn't work with GIT? Seems
>>> like the
>>> server should be based on the current version of GIT. New server -- Old
>>> client
>>> should work while Old server -- New client is just a recipe for
>>> problems.
>>>
>>> Arch currently has git 1.7.9.2-1. How far ahead of the
>>> scm.trinitydesktop.org is
>>> 1.7.9.2? Or, I guess the information I need is "What version of GIT is
>>> scm.trinitydesktop.org running?
>>>
>>> --
>>> David C. Rankin, J.D.,P.E.
>>>
>>>
>> I don't know - I found this problem last fall and just gave up. I think
>> it
>> must be on Tim's end. I would think a setting to be more likely the
>> problem
>> then the version number. A quick google search doesn't turn up anything
>> however.
>>
>> Calvin
>
> OK guys, first there is no such thing as a "GIT server" where the software
> is concerned.  What we call a "GIT server" is a box containing a
> well-secured central copy of the GIT tree, which can be accessed with HTTP
> over DAV via Apache.  No mattery where you go this is what you will find,
> except for a few places that use SSH for GIT access (which the recent
> kernel.org hack shows us is a Very Bad Idea BTW).
>
> So what we should actually be looking at is why Apache's DAV module is
> hanging up the connection early.  I'll see what I can do.
>
> Tim

SCM uses its own HTTP server, so some of this should be disregarded. 
Regardless I will look into the problem further, and the main point is
that there is no "GIT server" software--GIT relies on other protocols to
do its data transfer.

Tim