Hi Marius,
First, I would like you to congratulate you and Johan for the good work
and efforts you both put on this feature.
Then, I would like to say that I would be really really sad if SSH
support was deprecated. I think that providing your public key from a
user's point of view is really simple and I would to keep that behavior.
This would also easy the adoption for most people that are already used
to Github.
Also, we don't use git over HTTP at all in our company: just git:// and SSH.
Regarding simplifying installation, I would go with an official
automated installation recipe using either Opscode Chef or Puppet. As I
already created a Chef's recipe for installing Gitorious in Debian in
about 15 minutes if internet speed is good enough, it would be a matter
of making it official so that others can include support for non
Debian/Ubuntu systems too.
Then, comes my main concern. Until about an year ago, when I tried the
git plugin for Netbeans, which used JGit if I remember correctly, I had
several problems with corrupted git repository when using submodules.
Even if they corrected this, I don't trust the idea of re-writing the
git tools for Java. I would feel much more comfortable if they had
written a Cgit front-end instead, just like Grit does. And even that
happens, Grit is used in Gitorious just to read the file system, not to
write to it.
As long as SSH support is kept, I don't mind adding HTTPS push support
because I won't enable it anyway in our local installation. But I
wouldn't like to use gitorious.org for hosting my projects if I share
them with someone else and I can't make sure if he/she will use HTTPS
for pushing. Probably I wouldn't provide write access to anyone else
just to make sure only SSH will be used for pushing...
I really don't trust JGit and I don't trust current Java developers
either after lots of Java code I've been reading lately in largely used
Java libraries... It is like almost every good Java developers that
existed have now migrated to some better language, many of them still
running on JVM with languages like Scala, Closure, Groovy, JRuby, etc...
Well, that is my opinion. If the difficult of installing Gitorious is
the reason for dropping SSH support, I would reply that just writing an
official Chef's recipe would solve this problem.
Thanks for asking this on this list!
Best regards!
Rodrigo.
Em 24-06-2011 02:40, Marius Mårnes Mathiesen escreveu:
Anyone subscribed to this list will know that installing Gitorious is
not for the faint of heart. There are a lot of moving parts, a lot of
dependencies, and getting everything right is difficult. I really want
to change this.
One of the things that complicates the setup is that Gitorious is not
just a web app. It's also:
- a service running on top of SSH, using key infrastructure for
authentication and authorization
- a daemon that serves Git repositories over a dedicated protocol (git://)
- a service that provides Git access over HTTP
Historically, the only protocol that offered write access in Git was
SSH. The git protocol was mainly used because it's faster than HTTP
and doesn't require authentcation over SSH. These two things are the
main reasons why you want to run all these daemons on your server:
- SSH for push
- Git for fast, anonymous pull
Git's HTTP support changed a lot in version 1.6.6, introducing "smart"
HTTP. It's a fairly simple concept; a modern Git client will (if
supported by the server) open a series of HTTP POST requests to the
server, basically running regular git traffic (upload-pack and
receive-pack) over this connection. This means HTTP got a lot faster,
the performance is comparable to Git over SSH. And since HTTP supports
authentication (unlike the Git protocol) and encryption (SSL), this
means you can support all Git usage scenarios over a single protocol,
and stil be safe. Oh, and as a bonus, people stuck behind a firewall
can finally join the party too.
Gitorious' current HTTP support is based on the old (aka. dumb) HTTP
method (Scott Chacon has a really good write-up on the difference
between "smart" and "dumb" HTTP at
http://progit.org/2010/03/04/smart-http.html), which is slow,
error-prone, read-only and locks up your Apache/nginx workers serving
static files. Git itself has a cgi that provides smart HTTP, but
making it work in a scenario where the incoming URL is different from
the path on the file system involves hacking Git itself.
Christian and I have made a few experiments on implementing smart HTTP
for Gitorious, and this week we've been focusing on one of them: Mutt
[1]. Mutt is a cross breed (and also a git):
- It's written in Ruby
- It runs under JRuby
- It uses the awesome JGit library, which is an implementation of Git
in Java. JGit is used in EGit, the Git support in Eclipse, and in
Gerrit, the code review system used by the Android project
Mutt will provide anonymous/authenticated fetch/pull and authenticated
push to your Gitorious server. It will be awesome, and it will be
installed by a single command.
The question is: once we have an easily installed,
anonymous/authenticated, pull/push solution for Git traffic: is it
time to deprecate the other protocol handlers in Gitorious:
- The SSH handler
- The Git handler (git-daemon or git-proxy)
Would anybody miss them?
Discuss.
Cheers,
- Marius
[1]: https://gitorious.org/gitorious/mutt Yes, I know there's already
a program called Mutt, the name just fits really well. I promise we
won't name the binary mutt, and we won't read your .muttrc.
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
