GitHub

[Ian Monroe]

On Wed, Jan 7, 2009 at 4:38 AM, Nikolaj Hald Nielsen
<nhnfreespirit at gmail.com> wrote:
> I'll add my 2 cents...
>
> I won't get into the relative merits of GitHub or other hosted git
> solutions, but I will reiterate something that I have expressed on
> numerous previous occasions.
>
> For the bulk of the development we do, git is simply not the right
> tool for the job!
>
> A few reasons why I think this:
>
> 1. We are are about to move into the 2.1 development phase. This lets
> us commit everything to svn trunk again. All things being equal, svn
> trunk is where things mature, its is, as someone already mentioned,
> our interface point with new contributors, translators, many testers
> and so on.
>
> 2. Having everyone keep their own private git branches makes the
> direction of development much less transparent. This might really be
> more of a social issue than something specific to git, but I do fear
> that we would loose the sense of shared direction that svn trunk is
> giving us.
>
> 3. Even with git, merging is _not_ trivial. Already, several of the
> things I have in branches have run onto huge conflicts with stuff
> happening in trunk. And this has happened with just 2 separate
> "paths". When everyone is working in trunk, these conflicts are
> resolved "on the go" and are not allowed to snowball into really bad
> problems caused by the "paths" being separated for a very long time.
> This is an issue that will rapidly escalate if the development culture
> shifts to one where everyone keeps their projects close until they are
> almost done and then bulk commits.

I agree we shouldn't do that. We don't have to. Sometimes there is no
choice but to feature branch though.

> Now, that said, I am sure some of you will be quick to point out that
> I have more, large, git branches lying around than most of you. This
> is true, and for this sort of exploratory development, I think git-svn
> works... decently... even if there are many ways to hang yourself. But
> this is a special case, at a special time in the development flow. My
> goal is to get this stuff into svn as soon as possible as this is
> where I expect it to mature and get the kind of testing it needs.

Having feature branches does have disadvantages, but its certainly
nice to have it as an option.

> The main gist of the above is that I think git is likely to
> drastically reduce the transparency of the development in general. Not
> just because of the culture that git intrinsically promotes, but also
> in very large part because it will, at least for the time being be
> something that we graft on top of the main svn repo, at least unless
> we are willing to loose translations, bugfixes, and other
> collaboration with the greater KDE project.

We wouldn't loose translations if we were to actually do it. Obviously
loosing translation isn't an option so its silly to bring up a
contingency where we switch to git and loose them.

We just have to figure out how to get scripty to download our code
from git and do its scripty business. Translators would still commit
to SVN like normal.

I do think we can keep things officially KDE. There are other projects
interested in switching to git before the rest of KDE does. Aaron
Seigo expressed some interest in doing so with plasma (though
obviously he doesn't speak for the project as a whole, judging by the
people in #plasma at the time who complained @ that idea :P). So we
don't have to loose the random KDE bug fixers who stop by Amarok from
KDEland from time to time either.

> And finally, I am pretty sure that KDE will start to officially
> support git at some point in the future in any case which might make
> much of this discussion irrelevant anyway.

Hopefully but it might take some work from us to get it to budge...

Ian