[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Version mismatch when building trunk
From: Chani <chanika () gmail ! com>
Date: 2009-10-19 7:33:53
Message-ID: 200910190033.53997.chanika () gmail ! com
[Download RAW message or body]
On October 19, 2009 00:07:27 Johannes Sixt wrote:
> Thiago Macieira schrieb:
> > The branch switching is necessary in the workflow I created because I'm
> > treating kde-qt branches as patch queues. Each time I create a new
> > branch, I reapply all the previous patches from KDE, while local changes,
> > like backports from Qt itself, are lost. We start anew.
>
> You could create a branch latest-stable that merges 4.6-stable etc. such
> that the merge always takes the content of the merged-in branch. Then
> people need just track lastest-stable, and they will be fast-forwarded by
> the next git pull.
you missed the part where we talked about it not being fast-forward. :) or are
you saying there's a fast-forward way to merge? I guess if it was interactive
maybe... or if you reverted all the kde changes then merged in the latest qt
then reapplied the patches...
who's going to maintain such a branch, though?
or, could it be worth it to have a non-fast-forward branch (perhaps with
READONLY in the name)?
or am I talking nonsense? :)
the git commands with HEAD mean one extra line when updating, but git does
take away the apply-patches step. so overall it evens out ;) so long as you're
using it readonly, that is. which you probably should.
--
This message brought to you by eevil bananas and the number 3.
www.chani3.com
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic