Git policy for kde-baseapps?

[Frank Reininghaus]

Hi everyone,

(sending to kfm-devel and plasma-devel because I think that the vast
majority of bug fix commits in kde-baseapps is due to FolderView,
Konqueror, and Dolphin)

as far as I know, we never discussed (or even agreed on) a common
policy for the usage of git in kde-baseapps, in particular concerning
bug fix commits that should be both in the stable branch (currently
KDE/4.9) and master. It seems that most people (including myself)
cherry-pick changes from one branch to the other, but once in a while,
someone merges the stable branch into master instead. Unfortunately,
this messes up the output of 'git log' considerably and makes tools
like qgit and gitk mostly useless for understanding what's going on in
master because all cherry-picked commits appear twice. Therefore, I'd
like to propose a set of rules here, and I'd appreciate any comments
about them.

1. Before a commit, which is not a merge, is pushed to either the
stable branch or master, run 'git pull --rebase'. If the remote branch
has moved on since the last pull, this prevents the creation of a
superfluous and possibly confusing merge commit and keeps the output
of qgit and gitk clean. BUT: If the commit to be pushed is a merge, do
not run 'git pull --rebase' under any circumstances, see the
discussion in [1] for the possibly disastrous consequences.

2. Commit bug fixes, which are considered safe enough to be included
in the next bug fix release (at the moment, this would be KDE 4.9.2),
to the stable branch only. Someone will merge them to master from time
to time using 'git merge'. I wouldn't do this after every single
commit because this would needlessly pollute the history. Maybe it
would make sense to merge the stable branch into master

* just before any large change in master, to prevent that a later
merge of the stable branch would lead to conflicts,
* just before any beta release is made from master, to make sure that
all recent bug fixes are included in the beta packages, and
* around the time of bug fix releases from the stable branch, to make
sure that master users don't suffer from bugs which are fixed already
in released stable packages.

What do you think? An alternative to rule 2 would be to never merge,
but cherry-pick everything. But the disadvantage of this approach is
that a single merge (by accident or by someone who doesn't know the
rules) would make all commits appear twice in the history again. If,
on the other hand, the general policy is to only commit bug fixes to
the stable branch, and someone accidentally cherry-picks one commit,
there would be much less damage - only the single accidental commit
would appear twice.

I have committed my recent bug fixes to KDE/4.9 only, and I'll
continue to do this until we have agreed on a common git policy.

Best regards,
Frank

[1] http://lists.kde.org/?t=129715342800001&r=1&w=2