On Thu, 17 May 2007, Nicolas Pitre wrote:
On Thu, 17 May 2007, Jan Hudec wrote:
On Thu, May 17, 2007 at 10:41:37 -0400, Nicolas Pitre wrote:
On Thu, 17 May 2007, Johannes Schindelin wrote:
On Wed, 16 May 2007, Nicolas Pitre wrote:
And if you have 1) the permission and 2) the CPU power to execute such a
cgi on the server and obviously 3) the knowledge to set it up properly,
then why aren't you running the Git daemon in the first place? After
all, they both boil down to running git-pack-objects and sending out the
result. I don't think such a solution really buys much.
Yes, it does. I had 2 accounts where I could run CGI, but not separate
server, at university while I studied and now I can get the same on friend's
server. Neither of them would probably be ok for serving larger busy git
repository, but something smaller accessed by several people is OK. I think
this is quite common for university students.
Of course your suggestion which moves the logic to client-side is a good one,
but even the cgi with logic on server side would help in some situations.
You could simply wrap git-bundle within a cgi. That is certainly easy
enough.
isn't this (or something very similar) exactly what we want for a smalrt
fetch via http?
after all, we're completely in control of the client software, and the
useual reason for HTTP-only access is on the client side rather then the
server side. so http access that wraps the git protocol in http would make
life much cleaner for lots of people
there are a few cases where all you have is static web space, but I don't
think it's worth trying to optimize that too much as you still have the
safety issues to worry about
David Lang
-
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
