[Kde-pim] Git and the needs of KDE PIM

[Stephen Kelly]

Hi,

At the recent kde pim osnabrueck meeting we discussed the upcoming switch to 
git and how it affects kdepim.

I've rad through the wiki page and didn't see anything about it, so that 
means you don't know why git might not be an option for kde pim today, as I 
understand it.

http://techbase.kde.org/Projects/MovetoGit

We do want to move to git with the rest of kde, but we're not certain how 
git can be a replacement for svn and the way it is currently used to manage 
branches. Hopefully you can help us understand what needs to be done to make 
this happen.

kdepim has several active branches which regularly have patches merged 
between them. These are mainly the enterprise branches. Additionally, when 
doing merges, some individual commits are permanently blocked so that they 
are not merged into the main KDE stable branch with the rest when merged 
from one of the enterprise branches. Usually the reason for this is a new 
string added in the enterprise branch which can not be merged into the 
stable 4.x branch. This is managed by using svn properties.

If you need to know more about this stuff, hopefully Thomas McGuire can 
answer any questions.

As git can not do merges between different repos, we would need to have all 
of the branches in the same git repo possibly including all history from kde 
3.5. (Is it planned anyway to have all history in each module repo? That's 
not in the techbase page).

The "blocked" commits issue poses bigger problems I think. My knowledge of 
the internals of git is not strong, but I don't think it would be possible 
to identify commits to keep only in one branch and not merge with the rest. 
One option is rebasing, but I don't think git push --force will be allowed 
on the gitorious repos. 

Another option is cherry picking commits between the branches. I'm not sure 
if that would scale. Yet another option is that it might be possible to use 
git properties with a custom git command to read the properties and ignore 
certain commits and cherry pick the rest. If this works it has the 
disadvantage that anyone doing a merge would need to use the own-merge 
command instead of the regular git merge command. Another disadvantage would 
be that there is not record afaik in a cherry picked commit about where it 
came from.

This might all just be a solved problem in git in general, I'm not sure, but 
if you know please let us know. Maybe something like 

// Merge from before the blocked commit up to the blocked commit into 4.4 
git merge blockedcommit^ kde4.4 
// Merge from after the blocked commit up to HEAD into 4.4
git merge blockedcommit+1 kde4.4 

or 

// Merge from after one blocked commit upto another blocked commit into 4.4
git merge blockedcommit+1 anotherblockedcommit^ kde4.4 

Does something like this already work?

All the best,

Steve.



_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/