[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC PATCH v3 00/17] Return of smart HTTP
From:       Mark Lodato <lodatom () gmail ! com>
Date:       2009-10-16 23:04:45
Message-ID: ca433830910161604g5a6bde76n26eb2b1e8155fb36 () mail ! gmail ! com
[Download RAW message or body]

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]