Git policy for kde-baseapps?

[Frank Reininghaus]

Hi Dawit,

2012/9/26 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)

I think it has just been overlooked first that this commit is safe
enough to go into the 4.9 branch. I was the one who encouraged
Emmanuel to commit that fix to 4.9 as well. If you first fix something
in master and later decide that it can also be pushed to 4.9, I see no
other option but to cherry-pick.

> How can that be resolved or do we live with the duplicate log entries ?

I don't know how to avoid a duplicate entry in that case. But given
the big mess of duplicate entries that we had in the past every time
someone decided to merge, I think that a single duplicate entry is
something that we can probably live with.

> This
> is why I have simply been cherry picking my fixes from the 4.9 branch to the
> master branch all this time.

Yes, I did the same in the past. But every time someone merged the 4.9
branch into master, every single commit of mine showed up twice in the
history. This was my motivation to propose a set of rules how to use
git in kde-baseapps.

> 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...

Yes, people do whatever they want. However, if the majority follows
the 'merge' rather than the 'cherry-pick' strategy, I think that the
situation is better:

1. If most people go the 'merge' way and then someone cherry-picks a
commit instead, this single commit will show up twice in the history.

2. If most people cherry-pick and a single developer (maybe someone
who is not a regular contributor of kde-baseapps) decides to merge 4.9
into master, almost all commits appear twice in the history, which is
IMHO much worse. And yes, this has happened more than once in the
past.

Best regards,
Frank