Changes to our Git infrastructure

Ben Cooksley bcooksley at
Thu Dec 25 11:09:56 GMT 2014

On Fri, Dec 26, 2014 at 12:01 AM, Jan Kundr√°t <jkt at> wrote:
> On Thursday, 25 December 2014 11:06:05 CEST, Ben Cooksley wrote:
>> Not sure why random / 3rd party stuff would be imported - regardless
>> of whether it is a scratch repository or otherwise.
>> Distributions tend to frown upon bundling...
> I've had a need for this twice.
> The first instance was trying to fix breakage in Ragel, a 3rd party SW which
> generates parsers. It contained logic error related to cross compilation. I
> wanted a place to host my modifications, and because I run into that problem
> during my work on KDE, I wanted to use KDE's infra for that. I couldn't,
> because I wasn't able to import upstream's content into my personal scratch
> repo.
> The second case was a tool I wanted to use during my work on CI. It's not a
> SW library to be used by program we develop, but rather an existing tool
> which I wanted to extend with some additional level of functionality. Again,
> I wasn't able to import this due to the checking hooks, so I ended up using
> another hosting service.

Fair enough.

>>> Which might be fine, maybe we don't want people to use KDE's git for
>>> these
>>> purposes. What's the purpose of scratch repos?
>> For new development projects.
> That makes sense. If the scratch repos are not for hosting "random crap I
> need for my KDE work", but rather "new stuff I create for KDE", then having
> these hooks operating in this strict mode is OK. In that case the message
> about the purpose of the scratch space should probably be made a bit
> stronger, because I wasn't aware of this limitation despite being with KDE
> since 2007.

In most cases what is the rule on Git is simply an extension of what
was the rule with Subversion.
Sysadmin didn't change things.

> I'm not saying that limiting the intended use cases like this is necessarily
> bad. There's always Gitorious, GitHub, and other similar
> services. If we don't want to be in the business of providing KDE developers
> a universal Git hosting, we don't have to be. There's a downside, though,
> that people who already "have to use something non-KDE" might want to
> default to using these permissive, 3rd-party hosting services even for
> projects that "should be on git.k.o", simply because the other platform has
> worked well all the time before.

Fair point. This is another matter of policy which should probably be
reviewed at some point I guess.
The hooks do all have solid reasoning behind why they were implemented
though (the author metadata is particularly important for relicensing
and the like in the long run for instance) so we need to consider
these changes carefully.

>> This question was asked because some of the possible solutions out
>> there behave like Gitorious/Github and require a minimum level of
>> structure. If this was unacceptable then we'd need to exclude them
>> from the candidate shortlist.
> Ah, OK. I think it would be a bit short-sighted to eliminate a potentially
> more useful tool only on the basis of having a one-time config change. (My
> personal favorite doesn't require such a change.)
>> We've never had any problems with immediate propagation once a
>> repository exists except when a mirror is having some trouble.
>> At least not to my knowledge anyway.
> I've seen repeated problems with propagation delay of *force* pushes to
> git at . I think I
> mentioned them on IRC already.

It's news to me. "git remote update" should work (that is all the
immediate update system runs) to update a repository which has changed
(These repositories are setup in --mirror mode).

Guess that is something to add to the "to fix" list.

(One reason I want to get the list of what we want nailed down
semi-quickly - an improved anongit would have to work more closely

> Cheers,
> Jan
> --
> Trojit√°, a fast Qt IMAP e-mail client --


More information about the kde-core-devel mailing list