Sitaram Chamarty [off-list ref] writes:
Subject line says it all... While working with people trying to use
gitolite's new support for the "smart HTTP" mode, I find sometimes
they get side-tracked by this document.
Not everybody uses gitolite, and I do not think we have broken the dumb
HTTP support (however broken the original was ;-) to render the document
obsolete.
Perhaps we should do three and half things:
- The said documentation should be fine as is if the reader is trying to
set up a dumb HTTP push support; otherwise it should be updated.
- It would be really nice if somebody wrote a similar document describing
how to set up a smart HTTP server, and put it next to the said
documentation.
- When the above two is done, insert one line "This describes an older
way; see <<insert the name of the other document here>> for insn to set
up an experimental smart HTTP server" at the beginning of the original
document.
and finally:
- On the gitolite side, refer to the "new" document in git.git
documentation set.
On Fri, Oct 22, 2010 at 9:53 AM, Junio C Hamano [off-list ref] wrote:
Sitaram Chamarty [off-list ref] writes:
quoted
Subject line says it all... While working with people trying to use
gitolite's new support for the "smart HTTP" mode, I find sometimes
they get side-tracked by this document.
Not everybody uses gitolite, and I do not think we have broken the dumb
HTTP support (however broken the original was ;-) to render the document
obsolete.
My apologies; I didn't realise my mail would come across like that.
Let me clarify. "While working with gitolite users" was only meant to
explain how *I* came across the issue, nothing more.
I assumed that the new -- much more efficient (correct?) transport
would make the older (dumber) transport obsolete, and I didn't realise
it had any advantages over the new one.
Perhaps we should do three and half things:
- The said documentation should be fine as is if the reader is trying to
set up a dumb HTTP push support; otherwise it should be updated.
- It would be really nice if somebody wrote a similar document describing
how to set up a smart HTTP server, and put it next to the said
documentation.
I just followed "man git-http-backend" and it all worked. Should there be more?
- When the above two is done, insert one line "This describes an older
way; see <<insert the name of the other document here>> for insn to set
up an experimental smart HTTP server" at the beginning of the original
document.
and finally:
- On the gitolite side, refer to the "new" document in git.git
documentation set.
It does refer to the new one, otherwise no one would have been able to
use those instructions!
Just that some people... I don't know.. gloss over the exact filename
maybe... or they find the other one first and think it's the right
one...
Anyway, you're partly right -- I probably should highlight it better in my docs.
Thanks
--
Sitaram
Sitaram Chamarty wrote:
I assumed that the new -- much more efficient (correct?) transport
would make the older (dumber) transport obsolete, and I didn't realise
it had any advantages over the new one.
FWIW the old transport still has its place. If your web host (e.g.,
an ISP) allows only static content (no CGI), then there is no choice.
Not so relevant for gitolite but still relevant in the world.
Hope that helps,
Jonathan
On Fri, Oct 22, 2010 at 8:36 PM, Jonathan Nieder [off-list ref] wrote:
Sitaram Chamarty wrote:
quoted
I assumed that the new -- much more efficient (correct?) transport
would make the older (dumber) transport obsolete, and I didn't realise
it had any advantages over the new one.
FWIW the old transport still has its place. If your web host (e.g.,
an ISP) allows only static content (no CGI), then there is no choice.
Not so relevant for gitolite but still relevant in the world.
Also I now realise the new transport requires Apache, so people with
other web servers probably need it too.
I guess what remains is that the protocol is not efficient enough,
especially for normal push/fetch working-day interactions. I'll find
suitable wording that reflects all this...
thanks
sitaram
Sitaram Chamarty [off-list ref] writes:
On Fri, Oct 22, 2010 at 8:36 PM, Jonathan Nieder [off-list ref] wrote:
quoted
Sitaram Chamarty wrote:
quoted
I assumed that the new -- much more efficient (correct?) transport
would make the older (dumber) transport obsolete, and I didn't realise
it had any advantages over the new one.
FWIW the old transport still has its place. If your web host (e.g.,
an ISP) allows only static content (no CGI), then there is no choice.
Not so relevant for gitolite but still relevant in the world.
Also I now realise the new transport requires Apache, so people with
other web servers probably need it too.
Why do people think that "smart" HTTP transport requires Apache web
server? If I understand it correctly provided git-http-backend is a
simple CGI script, and requires CGI-capable web server and git
installed on server. Examples use Apache because probably that is
what author was familiar with. I don't see the reason why it
shouldn't work e.g. with nginx or IIS...
--
Jakub Narebski
Poland
ShadeHawk on #git