Re: [Coremu-list-devel] Updating COREMU to latest QEMU master

[Yufei C. <cyf...@gm...>]

On Tue, Oct 19, 2010 at 12:20 AM, Antti P Miettinen <an...@ik...> wrote:
> From: Chen Yufei <cyf...@gm...>
>> I rebased COREMU to the latest qemu a couple of weeks before and
>> fixed several problems to make x86_64 working.
>>
>> To my knowledge, rebased branch are not to be published, since other
>> people can't pull it again if I do a rebase later.
>>
>> Use merge can avoid the problem of rebasing. But it would be
>> difficult if we want to submit our change to upstream later.
>>
>> Do you have some suggestions on this subject?
>
> As far as I understand, rebase changes history so I can see how
> rebased branches in public trees are a problem. I have not run into a
> situation where I would want to do a rebase. I've been happy with
> fetch and merge. Diffing against master in a branch to which master is
> merged should look pretty similar to diffing a rebased branch. So why
> not just preserve the history? :-)

Rebase would give us a history with our modifications to qemu
consecutively. But the history results from merge would clutter our
modification with upstream's. So it's difficult to find our
modifications using merge. ('git diff --topo-order' would help a bit
on this problem.)

I've seen people maintaining two branch to keep up with upstream. One
uses rebase for own development and submitting patches to upstream;
the other uses merge to publish his own modifications. But this
approach requires extra work.

>
> Submitting the changes upstream would probably require splitting up
> the current work to small pieces. I have not thought how that would be
> organized in git - several small branches?
>
> --
> http://www.iki.fi/~ananaza/
>

-- 
Best regards,
Chen Yufei