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

[Thomas Koch]

Hi Stephen,

> 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. [...]
The handling of branches becomes much easier with GIT then with SVN. Creating 
a branch with GIT does not create a copy of all files of the original branch, 
but just creates a new pointer of a few bytes. Therefor GIT workflows usually 
make use of more branches then SVN workflows. However speaking of many 
branches often sounds scarry in the ears of SVN developers.
With GIT, you normally create a new branch for every new feature you develop. 
Once the feature is ready, you merge the feature branch back to the mainline 
and delete the pointer to the feature branch.
In your case, there are multiple mainlines: KDE stable and several enterprise 
branches. So when the feature is ready, just merge it in those mainline 
branches where it should appear.
This is only one possible solutions. There are many others possible.

> 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. [...]
Sorry, but GIT will happily merge between different repos. You could even have 
an inhouse repo with private branches and happily merge changes between the 
private and the public repo without disclosing anything you don't want.

> 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.
You can't (as in shouldn't) rebase anything that has already been pushed to a 
public branch because it invalidates the local clones of the other developers. 
See my comment above on how to separate features.

> 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.
Cherry-Picking would be another strategy I also thought of. However it would 
be needlessly complicated for your case, since you can easily solve your 
problems with feature branches.

    /-Feature A-\
   /             \
  /               \
-----KDE-mainline------------------------------------------------------>
 \                    \     \              /
  \                    \     \            /
   \                    \     -Feature B-<
    \                    \                \
     \                    \                \
      -Enterprise------------------------------------------------------>
        \           /
         \         /
          Feature C

Hope, I could help,

Thomas Koch, http://www.koch.ro