Version mismatch when building trunk

[Chani]

> 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.
> 
> And this "starting anew" is something that the tool was not designed for.
> That's why it's slightly cumbersome for you.
> 
> Like I said, we can change the workflow and just have one recommended
>  "master" branch. But since there will be no periodic cleanup done on it, I
>  will not maintain it and will ignore it when it comes to bug reports.
>

ohhhh. so the difference between the 4.5 and the 4.6 branches in kde-qt isn't 
fast-forward?
now this makes a bit more sense - I couldn't understand why you didn't just 
create a branch and make everyone happy. :)

would it be an option to have a "recommended" branch that gets hard-reset 
somehow to the latest branch, and tell people using that branch to pull -f? or 
would it cause trouble for other people using the repository?

it sounds like what we really want is some kind of movable tag... but git tags 
can't move...


btw, has anyone thrown that HEAD workaround up on techbase yet? :)

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091017/69fe5fa0/attachment.sig>