Em 24-06-2011 17:13, Christian Johansen escreveu:
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? :)
Right, sorry, Christian. It is just the new age's effect :)
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?
Because I want all my repository submodules URL to use git:// protocol
instead of HTTP and HTTP is enabled by default and I don't want to have
to worry about that explaining this to my coworkers. We don't have
firewall issues related to git:// protocol in our company. I find the
git protocol to be more lightweight than HTTP and usually supported
out-of-the-box by git tools and I want they to think that Gitorious is
just a web interface and that we could do everything without Gitorious
using other tools if we wanted...
It is important for me that they understand the concepts behind usual
Git workflow...
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).
I'm not sure I understood. Recipes can be fully configured to adapt to
each user's need and we could provide simple defaults the same way you
would do for gitorious-light.
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.
This is my concern: I've lost git commits due to JGit destroying the git
file-system. I definitely don't want to enable any write support of JGit
for my repositories... I think Gitorious currently don't use any write
support from Grit, right?
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
<http://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,
All of them about now ;)
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 don't mind in supporting HTTPS push. I just don't want any JGit write
support involved in this process... I'm all for it otherwise. It just
doesn't mean I'll use it myself, since I'm fine with SSH for our local
installation.
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 ;)
I didn't take a look at it, and as I said, I'm not even sure that NBGit
used JGit, but I know for sure that NBGit corrupted some repositories
with submodules. I just don't like the idea of reverse engineering git
and would prefer a front-end approach instead...
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.
It is from my best interest too ;)
Changing the subject, just as a brief update, I'm almost finished with
OpenID support with Devise. It is already working but I need to fix some
other existent problems in Gitorious regarding flash messages that are
currently not working correctly in the second generation layout and the
authentication view when errors happen. Also I need to make the test
pass, even if it means replacing it with an integration test...
But probably I'll only be able to continue on next weekend since I'm
leaving to a party now and will be out of town as soon as my wife and me
wake up tomorrow, returning on Sunday night probably...
Best regards!
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
