'latest' branch for kde-qt (was: kdelibs (tests) doesn't build against qt 4.6.0-tp1)

[Matthew Woehlke]

Thiago Macieira wrote:
> Em Quarta-feira 16. Setembro 2009, às 19.16.07, Matthew Woehlke escreveu:
>> Thiago Macieira wrote:
>>> You have to change branches because... it's a different branch.
>> ...which is a significant step backwards from qt-copy.
> 
> Yeah, duh. What did you expect?
> 
> qt-copy was the import of a tarball.

...which is convenient for people (/me waves) that want latest Qt 
(especially when trunk occasionally depends on a pre-release), but 
usually aren't interested in making changes to Qt.

> Forcing the update on you will not work. The reason why is because 4.5.2-
> patched contains commits that are not and will not be in 4.6.

As a serious question, why not? If they were legitimate patches for 4.5, 
why are they not acceptable for 4.6? If they are, they should be kept, 
no? If they are no longer applicable, then they should be reverted. 
Either way I don't see the problem.

> Git supports 
> updating branches, as long as the new branch tip is a descendant of the 
> current one.
> 
> If it doesn't contain all commits in the current branch tip, it's called 
> history rewriting. I can't do that. Well, I can, but it'll break for you 
> later.

Would this work?
- check out 'latest'¹
- revert patches that won't be kept after the update
- merge the next branch (e.g. 4.6-stable)
- tack on an "adjustment commit" dumping any changes from the previous 
'latest' that aren't in the new upstream²
- push this as new 'latest'
- pull from the new "parent" (in this example, 4.6-stable) frequently so 
that the head of 'latest' tracks the head of the parent and push the result

(¹ Right now 'latest' == 4.5.2-patched. In the future it will be a real 
branch that has the same contents as the named branch that is being 
tracked.)
(² Hopefully there won't be any!)

Is it perfect? No. Maybe not even "pretty", and you probably wouldn't 
want to submit patches off of it. Fortunately, git makes it really easy 
to migrate patch sets :-).

I'd be willing to do the branch cutovers (but someone will need to help 
me with what patches should be kept/dropped). I'm /not/ willing to do 
updates by hand, but I would hope that can be automated.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Sorry, but I can't look into that right now. I'm running low on 
sacrificial chickens.