Version mismatch when building trunk

[Chani]

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