From kde-core-devel  Mon Oct 19 07:33:53 2009
From: Chani <chanika () gmail ! com>
Date: Mon, 19 Oct 2009 07:33:53 +0000
To: kde-core-devel
Subject: Re: Version mismatch when building trunk
Message-Id: <200910190033.53997.chanika () gmail ! com>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=125593765714117

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