[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Version mismatch when building trunk
From:       Johannes Sixt <j.sixt () viscovery ! net>
Date:       2009-10-19 10:51:49
Message-ID: 4ADC44C5.7080907 () viscovery ! net
[Download RAW message or body]

Chani schrieb:
> 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...

Something that boils down to the latter:

o--o--o--o--o--o--o--o--o--o--o--o--o--o  <-Qt
    \                       \
     K--D--E <-4.6-patched   K'--D'--E'   <-4.7-patched
            \                         \
             `-------------------------M  <-latest-stable

Commit M would be generate by

  $ git merge --strategy=theirs 4.7-patched

i.e. M is not a real content merge, but only takes over the contents of
branch 4.7-patched. Someone who had checked out 4.6-patched can just "git
pull" and will be fast-forwarded to M, which is identical (in contents) to
4.7-patched.

[Except that --strategy=theirs does not exist; it has to be something like

    $ git merge --strategy=ours --no-commit 4.7-patched
    $ rm .git/index
    $ git read-tree 4.7-patched
    $ git commit
    $ git status
    $ git reset --hard && git clean -fd

but only for the maintainer of the branch, of course.]

> who's going to maintain such a branch, though?

Anybody can. Y'know this is git. Just make a fork of kde-qt and offer the
branch. I was even thinking about doing that myself after reading the
back-and-forth in this thread. But I'm too far away from hacking KDE these
days. (Yes, I'm just a backseat driver. :-)

-- Hannes

[prev in list] [next in list] [prev in thread] [next in thread]