Git policy for kde-baseapps?

[Dawit A]

I still do not see how this can work cleanly. People commit changes in
master and then backport them to the 4.9 branch. Which BTW was by far the
most common workflow before the switch over to git. As an example if you
attempt to 'merge'  kde-baseapps 4.9 branch into master right now, you will
get a duplicate log entry for the following commit which has been
cherry-picked into the 4.9 branch from master:

commit 8c4fa6e03b6b6acedf3a03eef5347f38680818fe
Author: Emmanuel Pescosta <emmanuelpescosta099 at gmail.com>
Date:   Wed Sep 12 19:33:28 2012 +0200

    Fixes Bug 305783 - dragging a file over a directory #c4
         does not expand the dir => Bug discovered: When you drag a
         item onto a folder-view-item and then move it away
         instantly before the autoactivation event is triggered
         (After 750ms), the folder will be opened anyway.

    BUG: 305783
    REVIEW: 106381
    FIXED-IN: 4.9.2
    (cherry picked from commit 9ab8bcd6aa3ce5d96ee380d5f22d77c2f0a38881)

How can that be resolved or do we live with the duplicate log entries ?
This is why I have simply been cherry picking my fixes from the 4.9 branch
to the master branch all this time. That and the fact that my attempt to
merge always screwed things up for me until recently because I failed to
understand that I should never do a rebase in a branch from which I push to
a remote repository. Anyhow, it would be nice to merge, but I do not see
how practical it is in the real word where people do whatever they know or
feel at ease with...

On Tue, Sep 25, 2012 at 11:44 AM, Frank Reininghaus <
frank78ac at googlemail.com> wrote:

> Hi,
>
> 2012/9/20 Luca Beltrame:
> > In data giovedì 20 settembre 2012 09:53:53, Daniel Kreuter ha scritto:
> >
> >> is already in the KDE 4.9 branch. Maybe we can regularly merge the
> >> latest stable branch into the master or next version branch, f.e. once
> >> a week?
>
> I'm not sure merging if once a week is really needed, but if someone
> volunteers to do it, I certainly don't object :-)
>
> > I think it would be a wise idea. For the record, I tried merging things
> > locally and came up with some (possibly minor) conflicts.
>
> Whenever a conflict occurs, merging ASAP is indeed the right thing to
> do, I think.
>
> > Also, would anyone be "qualified" to do a merge, or should this be done
> by
> > anyone who has the time for it?
>
> I think anyone can do it, provided that no merge conflicts occur or it
> is obvious how to resolve the conflicts. Usually, resolving conflicts
> by using 'git merge -Xours' to prefer the master version of a piece of
> code is probably the right way to go, but if the stable branch has a
> bug fix that is not in master yet but cannot be merged either, one
> should ask the person who has worked on the code for advice.
>
> Best regards,
> Frank
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20120926/dc179da5/attachment.htm>