HTTPS has one requirement that can cost more to provide a installation: It requires a unique ip address dedicated to that service and a valid certificate.
On Jun 24, 5:13 pm, Christian Johansen <[email protected]> wrote: > > First, I would like you to congratulate you and Johan for the good work and > > efforts you both put on this feature. > > Thanks, but my name is Christian. Johan stepped down, remember? :) > > > 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. > > We definitely want to keep the end-user experience nice and simple, no > worries. > > > Also, we don't use git over HTTP at all in our company: just git:// and > > SSH. > > If you could have well-performing, secure and easy-to-use HTTP pull/push, > then why wouldn't you use it? > > > 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. > > The recipes are great when you can spare an entire server. However, for more > low-end environments, I think it would be awesome to simply `gem install > gitorious-light` to get a bare, but working, system up an running (and one > that could later be migrated to the full Gitorious solution). > > > 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. > > JGit is under heavy development, and I don't have any trouble trusting it. > Also, we're only using it for a very limited set of functionality, which is > fairly easy to test and verify that works correctly. Grit also does stuff on > its own (i.e. in Ruby), and is not always right on the mark either. > > > 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... > > As I've already said many times, we will not deprecate a working solution in > favor of a less capable one, so this shouldn't be a concern. Apart from > that, I don't really get the sceptic attitude against HTTPS push? Why is it > important that only SSH is used for pushing? (Given that the usability issue > can be solved). > > > 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... > > Take a peak at the JGit code. The parts I've looked at are surprisingly good > ;) > > > > > 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! > > And thanks for responding - your feedback is greatly appreciated. > > Christian -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected]
