Re: [Qemu-devel] [RFC] QDev explicit constructors & destructors

[Peter Crosthwaite]

On Tue, Jun 23, 2015 at 12:10 PM, Liviu Ionescu <address@hidden> wrote:
>
>> On 23 Jun 2015, at 21:31, Peter Crosthwaite <address@hidden> wrote:
>>
>> List discussions should be fine, regardless of release cycle phase.
>
> I apologise to all those who considered my messages not appropriate for this 
> list or for this moment.
>
>> ... usually you see these kind of needs once you see the code.
>
> right
>
>> Given that you have something partially working,
>
> I have something fully working for my needs, i.e. I can run real-life 
> applications created by my plug-in wizard on the emulator without any 
> changes. currently only STM32F103RB is implemented, on Olimex STM32-H103 
> board, but copy/pasting code for other MCUs/boards is easy, I just delayed 
> this to be sure the existing code is ok.
>
>> can you create a
>> threaded patch series that contains both the QOM change (at the front
>> of the series) and the application of it (all the STM stuff) at the
>> back. I will review it on list and see if I can think of alternate
>> construction sequence.
>
> unfortunately the differences are too many and a simple git format-patch 
> between my branch and master creates 1480 files,

Have you actually done this many commits or is mainline activity
coming up in the change set? To handle the latter I suggest starting
from scratch.

git checkout -b new_branch
git reset origin/master
git status

This purges your git history and resets your new branch to be
mainlines history, but you will have all your changes now unstaged.

git add (use -p to get some interaction going), to create patches. If
you have usable commit messages from the original branch, use git
commit -c to recycle them.

If the future, you may find it simpler to rebase your branch
continually rather than merge mainline in periodically.

If you have large amounts of out-of-scope content, commit it all as a
patch that you don't send.

If you are confident your patches are conflict free you could use a
cherry-pick based approach, but this is safer for getting a tree state
that matches your working code.

Use git rebase -i and all its capabilities to refine the series after
you have a patch set.

> too many to be posted here. and manually creating new branches and moving 
> changes there is too labour intensive, at least for my current git knowledge.
>

It's a necessary evil of being downstream that you have a few branches going.


> I would really appreciate a Skype screen sharing session, it'll be much more 
> efficient.
>

Give it a go and let me know where it gets stuck.

Regards,
Peter

> I highly appreciate your help,
>
> Liviu
>
>