Thread (27 messages) flat view 27 messages, 10 authors, 2016-06-15

Re: Smart fetch via HTTP?

From: <hidden>
Date: 2016-06-15 22:43:10

On Thu, 17 May 2007, Nicolas Pitre wrote:
On Thu, 17 May 2007, Jan Hudec wrote:
quoted
On Thu, May 17, 2007 at 10:41:37 -0400, Nicolas Pitre wrote:
quoted
On Thu, 17 May 2007, Johannes Schindelin wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help