From: Mark Lodato <lodatom@gmail.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH v3 00/17] Return of smart HTTP
Date: Fri, 16 Oct 2009 19:04:45 -0400 [thread overview]
Message-ID: <ca433830910161604g5a6bde76n26eb2b1e8155fb36@mail.gmail.com> (raw)
In-Reply-To: <20091016143154.GS10505@spearce.org>
I just realized I forgot to say something in my last email: THANK
YOU!!! I have been looking forward to this for a long time. I was
planning to one day to sit down and start thinking about how to
implement a smart protocol, and then I see a post saying that not only
has someone figured out the protocol, but he has implemented it!
Amazing! This is really crucial for corporate adoption, at least at
my job. We need to have strong authentication for many users, and the
SSH key management is just a nightmare, not to mention that not all
users can SSH due to firewalls. This will save me so much time and
frustration. Thanks!
On Fri, Oct 16, 2009 at 10:31 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> If users don't want to upgrade, or can't upgrade, then you can't
> push over HTTP. Simple.
Yeah, I realized after I wrote my previous email that it probably
doesn't matter - the current state of HTTP push is so awful that no
one probably uses it!
> Really, what it comes down to is, I don't think it matters that
> we don't have backwards compatiblity for pushing through WebDAV.
> If you think it matters, you are free to write a patch series on
> top of mine which adds the functionality. But don't wait for me
> to do it, it won't happen.
Agreed. I was just wondering if it was on the to-do list for the far
off future. Either way, it should probably be noted in the
documentation that dumb push is not supported.
>> Also, your examples use "DocumentRoot /pub/git", but I think most
>> people would want to have their main website as the DocumentRoot, have
>> the URL "/git" serve the repositories through gitweb, and have that
>> same "/git" URL be `git clone'-able.
>
> Why not have git-http-backend exec gitweb when it gets a request
> for the repository itself? Why do you have to go through such
> contortions in Apache for this? The two CGIs are shipped in the
> same software package, surely one could actually invoke the other.
>
> [snip]
>
> Yes, I'd like to have examples in the git-http-backend manpage.
> I put a couple in there already, but they don't consider gitweb
> because I assumed we'd find a way to have gitweb be invoked out
> of git-http-backend. Unfortunately that hasn't happened yet.
The gitweb part is just bonus. (The only thing for gitweb is the one
ScriptAlias line.) The real challenge is getting git-http-backend to
serve repositories out of something other than DocumentRoot - say
DocumentRoot is /var/www/htdocs but your git repositories are in
/pub/git - which is why I posted the configuration. If you'd like, I
can send you a patch to add this to the documentation.
One idea to improve the situation is to first try
$GIT_PROJECT_ROOT$PATH_INFO, falling back to $PATH_TRANSLATED if
$GIT_PROJECT_ROOT is empty. This would make the configuration simple:
-- 8< --
SetEnv GIT_PROJECT_ROOT /pub/git
ScriptAlias /git /usr/libexec/git-core/git-http-backend
-- >8 --
As far as having git-http-backend launch an external process such as
gitweb, I personally don't think this is important enough to block
this from continuing. One could configure the webserver as I have in
my previous email until such a feature is implemented. For cgit, the
solution is simple - just integrate git-http-backend into the
executable.
Regards,
Mark
next prev parent reply other threads:[~2009-10-16 23:04 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-15 3:36 [RFC PATCH v3 00/17] Return of smart HTTP Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 01/17] pkt-line: Add strbuf based functions Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 02/17] pkt-line: Make packet_read_line easier to debug Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 03/17] fetch-pack: Use a strbuf to compose the want list Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 04/17] Move "get_ack()" back to fetch-pack Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 05/17] Add multi_ack_detailed capability to fetch-pack/upload-pack Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 06/17] remote-curl: Refactor walker initialization Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 07/17] fetch: Allow transport -v -v -v to set verbosity to 3 Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 08/17] remote-helpers: Fetch more than one ref in a batch Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 09/17] remote-helpers: Support custom transport options Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 10/17] Move WebDAV HTTP push under remote-curl Shawn O. Pearce
2009-10-19 2:59 ` Tay Ray Chuan
2009-10-28 1:08 ` Shawn O. Pearce
2009-10-28 11:01 ` Tay Ray Chuan
2009-10-25 15:19 ` [PATCH 2/7] http-push: allow stderr messages to appear alongside helper_status ones Tay Ray Chuan
2009-10-15 3:36 ` [RFC PATCH v3 11/17] Git-aware CGI to provide dumb HTTP transport Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 12/17] Add stateless RPC options to upload-pack, receive-pack Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 13/17] Smart fetch and push over HTTP: server side Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 14/17] Discover refs via smart HTTP server when available Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 15/17] Smart push over HTTP: client side Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 16/17] Smart fetch " Shawn O. Pearce
2009-10-15 3:36 ` [RFC PATCH v3 17/17] Smart HTTP fetch: gzip requests Shawn O. Pearce
2009-10-15 7:39 ` [RFC PATCH v3 00/17] Return of smart HTTP Junio C Hamano
2009-10-15 9:52 ` Nanako Shiraishi
2009-10-15 14:33 ` Shawn O. Pearce
2009-10-15 15:21 ` Johan Herland
2009-10-15 15:41 ` Shawn O. Pearce
2009-10-15 20:27 ` Junio C Hamano
2009-10-15 20:45 ` Shawn O. Pearce
2009-10-22 10:21 ` Nanako Shiraishi
2009-10-22 14:46 ` Daniel Barkalow
2009-10-27 4:55 ` [PATCH] Fix memory leak in transport-helper Daniel Barkalow
2009-10-27 14:11 ` Johannes Schindelin
2009-10-27 17:37 ` Daniel Barkalow
2009-10-27 18:31 ` Jeff King
2009-10-27 18:54 ` Johannes Schindelin
2009-10-27 19:05 ` Daniel Barkalow
2009-10-28 7:18 ` Junio C Hamano
2009-10-16 4:20 ` [RFC PATCH v3 00/17] Return of smart HTTP Mark Lodato
2009-10-16 14:31 ` Shawn O. Pearce
2009-10-16 23:04 ` Mark Lodato [this message]
2009-10-16 23:16 ` Shawn O. Pearce
2009-10-22 19:48 ` Marcus Camen
2009-10-25 15:16 ` [PATCH 0/6] http: push and test fixes Tay Ray Chuan
2009-10-25 15:18 ` [PATCH 1/7] http-push: fix check condition on http.c::finish_http_pack_request() Tay Ray Chuan
2009-10-25 15:20 ` [PATCH 3/7] http-push: add more 'error <dst> <why>' status reports Tay Ray Chuan
2009-10-25 15:21 ` [PATCH 4/7] t5540-http-push: expect success when pushing without arguments Tay Ray Chuan
2009-10-25 16:16 ` Clemens Buchacher
2009-10-25 15:22 ` [PATCH 5/7] t5540-http-push: check existence of fetched files Tay Ray Chuan
2009-10-25 16:49 ` Clemens Buchacher
2009-10-25 15:23 ` [PATCH 6/7] t5540-http-push: when deleting remote refs, don't need to branch -d -r Tay Ray Chuan
2009-10-25 15:24 ` [PATCH 7/7] t5540-http-push: remove redundant fetches Tay Ray Chuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca433830910161604g5a6bde76n26eb2b1e8155fb36@mail.gmail.com \
--to=lodatom@gmail.com \
--cc=git@vger.kernel.org \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).