I'm doing a little work on Tupi -- the 2D animation application that joined the KDE community some months back -- so that it builds on FreeBSD (the C++ code is wonderful, but the build system is qonf, which is not).

This has led me to the maze of git documentation on KDE's infrastructure, and I'm taking notes so I don't forget what I did. It's also part of one of the things-to-do-at-Akademy on my list: talk to the techbase people to find out what the status and intentions are.

For the purpose of futzing with the build system, I'm using a personal clone of the repository. This is so that whatever weird-ass things I'm doing, they don't pollute the upstream repository; eventually I hope to code-dump a CMake-based buildsystem into upstream. One that can live alongside the existing build system for platforms other than FreeBSD -- although I think that in the long run having the same build system and dependency-finding-modules as all the rest of the KDE software would be good.

Basic git configuration is covered on techbase, which describes the mandatory (username) and optional (URL rewriting, colors, templates and exclusions) configurations for using git with the KDE infrastructure.

The KDE sysadmin git FAQ explains how to create a personal clone of a project repository. I've created a personal clone of tupi, and cloned that one locally. Then I work on that (in a project Neon VM and a FreeBSD jail).

The only thing is, my personal clone doesn't get updates from the upstream (here, that means the original project repository) unless I pull them in myself. This is where additional remote repositories come from. In my clone, by default there's two origin remotes (one for pull from anongit, one for push over ssh, as documented in the git configuration page).

[adridg@beastie]$ git remote -v
origin  git.kde.org:clones/tupi/adridg/tupi-cmake (fetch)
origin  git.kde.org:clones/tupi/adridg/tupi-cmake (push)


So what I need to do locally is pull in commits from the upstream, merge all of them with my local clone, and then push (which goes to my personal clone on KDE infrastructure). The git-scm book has clear instructions; for me it means adding an upstream repository:

[adridg@beastie]$ git remote add upstream kde:tupi


And then to keep up-to-date with the upstream commits and store them in my own personal copy, I need to do these four steps (this assumes that I don't do anything in the master branch myself):

[adridg@beastie]$ git fetch upstream
[adridg@beastie]$ git checkout master
[adridg@beastie]$ git merge upstream/master
[adridg@beastie]$ git push


There's probably a faster / better way of doing this, but at least I know I can keep up with the upstream. Now I can keep rebasing my work inside my local clone onto the latest upstream like this, until such a time as I'm ready to push my CMake branch to my personal clone on the KDE infrastructure. Once that's done, I can ask the maintainer to pull it into upstream.