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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
