[Kde-scm-interest] KDE PIM branches workflow with git

Johannes Sixt j.sixt at viscovery.net
Fri Mar 12 15:34:31 CET 2010


Stephen Kelly schrieb:
>  On Friday 12 March 2010 14:56:30 Stephen Kelly wrote:
>> > In particular, I would not use a special "Enterprise5-features" branch.
>> > Rather, I would create a separate feature branch for each feature that
>> > you invent. Then you can merge the features selectively to "KDE master"
>> > and "Enterprise5-release".
> 
> Actually I think I misread your paragraph when I replied. We'd create a
> separate branch for each feature and merge that into the e5-features
> branch. That branch can always be merged into master and e5-release by
> definition and gives us both a tracking point (if a merge from it is a
> no-op, the features are already in the target branch) and separation
> (the features branch contains no BiC hacks, and can always be merged to
> master).

Is "KDE master" the community's KDE? If so: does the community always want
*all* features that you invent? Does it never happen that you (KDAB) want
or need a feature, but the community does not want it (for whatever
reason, e.g. licensing)? If the community rejects a feature, then it
cannot merge your "Enterprise5-features" branch. For this reason, I
suggest to keep separate feature branches.

[Oh, you say: "can be merged into master by definition", so the answer to
my second question is yes.]

Of course, for KDAB internal reasons it might make sense to collect all
features in "Enterprise5-features" branch. But for the exchange with the
community, individual feature branches are better. (And those feature
branches must *not* originate from your internal branches, obviously.)

>> > The way that you proposed it, you would be able to
>> > merge features to "KDE master" and "Enterprise5-release" only
>> > collectively.
> 
> I don't think this is a problem?

See above: It's (only) a problem if "KDE master" does not want one of the
features.

> It does reduce the number of merge
> commits onto master, right?

What's bad with merge commits? When the --first-parent log of the master
branch lists N commits of the form

 Merge branch 'imap-over-ssl-speedup'
 Merge branch 'issue-345-db-corruption-after-power-failure'
 ...

I know a lot more than when it said only once

 Merge branch 'Enterprise5-features'

(This implies that I suggest to be rather verbose with feature and bugfix
branch names.)

-- Hannes



More information about the Kde-scm-interest mailing list