Merge or Cherry-Pick?

Alexander Neundorf neundorf at kde.org
Tue Feb 1 19:05:32 GMT 2011


On Monday 31 January 2011, Andreas Pakulat wrote:
> Hi,
>
> something that hasn't been written down as far as I can see (if I
> overlooked it, please point me to it) is what the policy on kdelibs is
> to be now wrt. merging vs. cherry-picking of changes in branches and
> master?
>
> Andreas


Not replying to any particular response in this thread...

I don't know whether I missed something, if so, please let me know.

I asked two weeks ago (http://lists.kde.org/?t=129546074300005&r=1&w=2) 
whether there is a commit/merge/push workflow defined for working on kdelibs 
etc.

This is what I got as response:

On Wednesday 19 January 2011, Ian Monroe wrote:
> > Can somebody please add a simple step-by-step howto, what I have to do
> > with identity.kde.org, projects.kde.org and git.kde.org, how the git
> > push/merge/branching policy is for KDE, etc. If there are existing blog
> > articles about this, please add links to them in a good visible place.
>
> There is no push/merge/branching policy for KDE. Different projects
> will likely do their own thing. For the time being its just the
> SVN-style development translated to Git.

This looks to me like "do what you want, there is no policy".

Now I see many people here arguing about things like cherry-picking and 
merging to 4.6 first and then merging or whatever.
Do we have a policy in the meantime ? Where is it ?

If not, this means I'm free to do what I want ?
Like, just pulling and pushing every single commit ?

IOW, how am I supposed to use git 
* for committing a trivial change to master/trunk
* for committing a bugfix to a stable branch
* for committing something non-trivial, but not really big  ?

Alex




More information about the kde-core-devel mailing list