[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