[Kde-scm-interest] KDE Git hosting status update

[Johan Sørensen]

2010/6/11 Jeff Mitchell <mitchell at kde.org>:
[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