From kde-scm-interest Fri Jun 11 13:00:27 2010 From: =?ISO-8859-1?Q?Johan_S=F8rensen?= Date: Fri, 11 Jun 2010 13:00:27 +0000 To: kde-scm-interest Subject: Re: [Kde-scm-interest] KDE Git hosting status update Message-Id: X-MARC-Message: https://marc.info/?l=kde-scm-interest&m=127626127103634 2010/6/11 Jeff Mitchell : [snip] >> -------------------------------------------------------------------------------- >> SUM:                           2740          43131          44892 >>   250546 >> -------------------------------------------------------------------------------- >> >> >> So, sorry for publishing bullshit numbers. > > Well, according to cloc it's not bullshit. There's clearly a large > disconnect here between what cloc says and what the Gitorious guys are > saying -- by nearly two orders of magnitude. I'd be interested in > knowing if the Shortcut guys have an explanation for the huge difference. Everything in vendor/ can basically be excluded (at least in my opinion) as that is third-party libraries and frameworks such as Rails. If you decide that should be included, then cloc is probably correct... > >>> Secondly, gitorious.org does in fact use the native git-daemon, but >>> the document seems to confuse cloning and pushing on a few occasions. >>> Pushing is entirely done through SSH and once the initial auth with >>> gitorious is done, it's passed along to the git machinery. >> >> The point was though that the script that gets called as login >> shell on SSH connect relies on the Rails process to be running, >> which is a pretty big affair, while gitolite doesn't have any >> continually running daemon process involved in push access. > > I've read through the document a few times and don't see where there's > any confusion as to git daemons. Gitorious does indeed have a custom git > daemon (which you refer to as a proxy, which is a fair assessment), > necessary to resolve the friendly URL names into the on-disk layout. > This does mean that if the native upstream Git git-daemon acquires new > features or capabilities that we'd have to code it into your git-daemon > or wait for an update. I was referring to this section: " The software uses a custom git-daemon, which it uses to control push access. This means that future features of Git (such as improved compression) are unavailable to KDE in the long term unless Shortcut updates their git-daemon or we update it ourselves." Which confuses a few terms (probably by accident), since the git-daemon (which handles the git:// protocol) has nothing to do with pushing. For pushing, over SSH, no protocol (apart from executing commands) mangling is involved, especially not concerning compression as that is handled by the git pack plumbing as with every other normal git fetch and push. Controlling push is not done by reimplementing git features or anything else the quoted paragraph hints at, it's simply leveraging the hooks infrastructure, much the same way I'm guessing gitolite does with the difference being from where it's fetched from, (I think) gitolite uses a file-based approach like gitosis, whereas gitorious asks the web server through a tiny HTTP API. For cloning over the git protocol, gitorious.org, the web site, uses a thin layer 7 proxy that grabs the git:// request url out of the initial protocol line and replaces it with something else before handing it on to one of several git-daemon backends (the C one, included with git-core), after that no mangling is done on the protocol level. It is not included in the public Gitorious code since practically every other gitorious installation isn't even close to handling the load gitorious.org does, so the ruby git-daemon (included with gitorious) is enough for most cases, as it will handle a large amount of requests easily. Should the git protocol change drastically overnight in a non backwards-compatible way, obviously the gitorious codebase would need to be updated as we have... a certain dependency on it working. Anyway, in the end it doesn't matter for you guys anymore as you've made a different choice already. I just wanted to point out a few smaller errors that I saw as a developer of Gitorious (as you know, these things have a tendency to be suddenly taken as facts down the line). >>> Just wanted to clear up some misconceptions and wish you guys good >>> luck onwards! There's no hard feelings from our side for choosing >>> something else, the important thing is leaving SVN behind ;) >> >> Thanks, and we definitely wish you guys all the best going >> forward, too - Gitorious.org is a great service, and the onus >> will be on us to try and live up to its example. > > Yeah. Gitorious.org is great -- we have just decided that given a > self-hosting constraint that there are tools that better fit our needs. > > --Jeff > > Cheers, JS _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest