> 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]
