[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: Re: Git policy for kde-baseapps?
From: Dawit A <adawit () kde ! org>
Date: 2012-09-26 14:57:18
Message-ID: CALa28R4cJm8e8tWMX=1UmA+qMvkPg4YaUpGUR7=W=y0oauBEnw () mail ! gmail ! com
[Download RAW message or body]
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@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@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
>
[Attachment #3 (text/html)]
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:<div>
<br></div><div><div>commit 8c4fa6e03b6b6acedf3a03eef5347f38680818fe</div><div>Author: \
Emmanuel Pescosta <<a \
href="mailto:emmanuelpescosta099@gmail.com">emmanuelpescosta099@gmail.com</a>></div><div>Date: \
Wed Sep 12 19:33:28 2012 +0200</div>
<div><br></div><div> Fixes Bug 305783 - dragging a file over a directory \
#c4</div><div> does not expand the dir => Bug discovered: When you \
drag a</div><div> item onto a folder-view-item and then move it \
away</div>
<div> instantly before the autoactivation event is triggered</div><div> \
(After 750ms), the folder will be opened anyway.</div><div> </div><div> \
BUG: 305783</div><div> REVIEW: 106381</div><div> FIXED-IN: 4.9.2</div>
<div> (cherry picked from commit \
9ab8bcd6aa3ce5d96ee380d5f22d77c2f0a38881)</div><div><br></div><div>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...</div>
<br><div class="gmail_quote">On Tue, Sep 25, 2012 at 11:44 AM, Frank Reininghaus \
<span dir="ltr"><<a href="mailto:frank78ac@googlemail.com" \
target="_blank">frank78ac@googlemail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
Hi,<br>
<br>
2012/9/20 Luca Beltrame:<br>
<div class="im">> In data giovedì 20 settembre 2012 09:53:53, Daniel Kreuter ha \
scritto:<br> ><br>
>> is already in the KDE 4.9 branch. Maybe we can regularly merge the<br>
>> latest stable branch into the master or next version branch, f.e. once<br>
>> a week?<br>
<br>
</div>I'm not sure merging if once a week is really needed, but if someone<br>
volunteers to do it, I certainly don't object :-)<br>
<div class="im"><br>
> I think it would be a wise idea. For the record, I tried merging things<br>
> locally and came up with some (possibly minor) conflicts.<br>
<br>
</div>Whenever a conflict occurs, merging ASAP is indeed the right thing to<br>
do, I think.<br>
<div class="im"><br>
> Also, would anyone be "qualified" to do a merge, or should this be \
done by<br> > anyone who has the time for it?<br>
<br>
</div>I think anyone can do it, provided that no merge conflicts occur or it<br>
is obvious how to resolve the conflicts. Usually, resolving conflicts<br>
by using 'git merge -Xours' to prefer the master version of a piece of<br>
code is probably the right way to go, but if the stable branch has a<br>
bug fix that is not in master yet but cannot be merged either, one<br>
should ask the person who has worked on the code for advice.<br>
<br>
Best regards,<br>
Frank<br>
</blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic