Changes to our Git infrastructure

Jan Kundr√°t jkt at
Mon Dec 29 16:36:05 GMT 2014

On Monday, 29 December 2014 17:03:25 CEST, argonel wrote:
> Personal clones are for forks. If you can't get a patch set accepted by
> "upstream", its equally unlikely that "upstream" are going to let you put a
> private branch in their repo for sharing that patch set.

This is a social issue, then. What yuo describe makes sense -- if a patch 
is extremely dirty, for example, I can imagine a project maintainer not 
willing to "carry it" as a visible branch in their repo.

However, the personal prefixes appear to solve this problem semi-neatly. A 
perfect solution would be refs that aren't getting included in clones (and 
guess what, there's one review system which works exactly like that).

> I'm sure I'm not
> the only one carrying patches that are arguably sharable but not
> upstreamable.

Got an example so that I know what you're describing?

> I've also used clones to share an experiment that may not belong in the
> proper repo now or ever. Making everyone who uses the main repo "pay" to
> carry an experimental branch is somewhat unfriendly, especially if you're
> not normally involved with the project. You may also wish to avoid the
> scrutiny of the others involved in the main project until you're ready,
> which the sudden appearance of a new branch during checkout would certainly
> invite.

That's a valid concern. On the other hand, it's a pretty simple way of 
"enforcing collaboration". There were keynotes during the last Akademy 
where people mentioned their worrying about development moving into 
isolated silos. Disabling clones leads directly to sort of an enforced 
collaboration (or, failing that, to people pushing stuff to GitHub).

> As I see it, scratch repos are the first stage in a project's life cycle.
> Before playground, you might fiddle with something, drop it in a scratch
> repo and share the link on IRC. Deleting it is painless when you discover
> that your idea is terrible, or already exists elsewhere.

I agree with scratch repos being useful as a first step.

> There are probably still quite a few people away for the holiday season,
> perhaps this decision can be deferred for a couple of weeks until its more
> likely that everyone is back and paying attention?

+1, and sending a mail to kde-cvs-announce to make sure all KDE account 
holders are aware of both this and the other thread is a good idea.

With kind regards,

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

More information about the kde-core-devel mailing list