Thursday, June 24, 2010

A Flashback of Kate in Gitorious

Back in February, I blogged about Kate's move to gitorious. The main reason for this move was to make building Kate as easy as possible. If you want to build Kate as part of KDE, (as of now) you have to compile kdesupport, phonon, dbusmenu-qt, kdelibs, kdepimlibs, kdebase for kwrite and kdesdk for the kate application. Getting all this done is a huge effort, especially if you are new to KDE development (I very well remember my own times spending weeks to get everything going. Be aware of new contributors might now close to nothing about KDE and all the dependencies!).As getting new contributors is essential for keeping a project alive, the barrier to get involved should be as low as possible. And exactly this was achieved by moving all pieces to one place (this was gitorious for us). Building Kate is so simple right now that we can even make bug reporters build Kate out of the box. This helps a lot, and even results in patches from time to time. We also got quite some merge requests.There were several voices at that time that considered moving "away from KDE" was very bad. However, this is not the case, as Christoph is synchronizing all the changes in KDE's subversion and gitorious almost every day. This is certainly not optimal, but looking back at the last months, we can say it was worth it.KDE is moving to git.kde.org in the near future. This also raises the discussion about how KDE's source code will be organized. Speaking for Kate, we certainly want to have all of Kate's code in one place, just as it is now with gitorious, no matter what :) I hope we can find a solution the KDE community can live with. To be discussed, maybe in Tampere in two weeks? :)

I think you'll have a hard time doing that, as git submodule's support is simply not able to fetch just a subdir of another repo. So you'd have to split up at least kte+katepart+rest into 3 repositories and then use git-submodule inside kdelibs and in a meta-repository "kate" to get everything in one go. However working with git submodule's is a bit more cumbersome than without.

There's an example of importing a git repository into another as a subdir in the git-history itself that also allows for still working in the original tree. But that would probably still need separate repositories.