Tim, all,
I am working on build scripts that will individually pull or update the source by pulling code from the git tree. To make this more efficient for building individual modules (and reduce unneeded bandwidth), it is recommended to use the git clone form:
git clone --depth 1 http://scm.trinitydesktop.org/scm/git/whatever
But http://scm.trinitydesktop.org/scm/git/ refuses to allow '--depth 1' to be used in the git clone. Anybody know why? The error received is:
Cloning into 'libart-lgpl'... error: RPC failed; result=22, HTTP code = 500 fatal: The remote end hung up unexpectedly
It works fine without the --depth limitation. What say the 'git' masters?
Firstly i have to say that my git jitsu is not strong.
Is the received immediately or after some time of hanging?
If the former i would suspect a problem with the handshake while using a shallow scope. In the latter case it could be timing out because of the size of the tree or a particular file in the tree. This can happen when pushing larger git files over http protocol. Perhaps you could try adding something like: git config http.postBuffer 524288000
Try using https if it is supported.
Jay
On Thu, Feb 23, 2012 at 8:23 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
Tim, all,
I am working on build scripts that will individually pull or update the source by pulling code from the git tree. To make this more efficient for building individual modules (and reduce unneeded bandwidth), it is recommended to use the git clone form:
git clone --depth 1 http://scm.trinitydesktop.org/scm/git/whatever
But http://scm.trinitydesktop.org/scm/git/ refuses to allow '--depth 1' to be used in the git clone. Anybody know why? The error received is:
Cloning into 'libart-lgpl'... error: RPC failed; result=22, HTTP code = 500 fatal: The remote end hung up unexpectedly
It works fine without the --depth limitation. What say the 'git' masters?
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 02/23/2012 05:38 PM, Jay wrote:
Firstly i have to say that my git jitsu is not strong.
Is the received immediately or after some time of hanging?
If the former i would suspect a problem with the handshake while using a shallow scope. In the latter case it could be timing out because of the size of the tree or a particular file in the tree. This can happen when pushing larger git files over http protocol. Perhaps you could try adding something like: git config http.postBuffer 524288000
Try using https if it is supported.
Jay
Jay,
This happens immediately. You don't have time to blink and you get the error:
Cloning into 'libart-lgpl'... error: RPC failed; result=22, HTTP code = 500 fatal: The remote end hung up unexpectedly
So I think your suspicion of "a problem with the handshake while using a shallow scope" is right on. Since I learned git a few days ago, your git jitsu has much "more focus" than mine :)
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
On Thu, Feb 23, 2012 at 9:46 PM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
On 02/23/2012 05:38 PM, Jay wrote:
Firstly i have to say that my git jitsu is not strong.
Is the received immediately or after some time of hanging?
If the former i would suspect a problem with the handshake while using a
shallow
scope. In the latter case it could be timing out because of the size of
the tree
or a particular file in the tree. This can happen when pushing larger
git files
over http protocol. Perhaps you could try adding something like: git
config
http.postBuffer 524288000
Try using https if it is supported.
Jay
Jay,
This happens immediately. You don't have time to blink and you get the error:
Cloning into 'libart-lgpl'... error: RPC failed; result=22, HTTP code = 500 fatal: The remote end hung up unexpectedly
So I think your suspicion of "a problem with the handshake while using a shallow scope" is right on. Since I learned git a few days ago, your git jitsu has much "more focus" than mine :)
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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?
On 27 February 2012 11:16, David C. Rankin drankinatty@suddenlinkmail.comwrote:
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
On 27 February 2012 11:16, David C. Rankin drankinatty@suddenlinkmail.comwrote:
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
On 27 February 2012 11:16, David C. Rankin drankinatty@suddenlinkmail.comwrote:
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
On 02/27/2012 11:40 AM, Timothy Pearson wrote:
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
Roger!
I guess Darrell is better at pretending he knows what he's doing than I am :)
On 27 Feb 2012, Timothy Pearson spake thusly:
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).
In the vast majority of places you will find git uses its own protocol for anonymous git access. A *lot* of places use ssh for non-anonymous access -- I would say the vast majority. You don't need to provide a whole shell on the other end, thanks to gitolite and friends.
-
Calvin Morrison -
David C. Rankin -
Jay -
Nix -
Timothy Pearson