On Tue, Jun 23, 2015 at 12:10 PM, Liviu Ionescu <i...@livius.net> wrote: > >> On 23 Jun 2015, at 21:31, Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> 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 > >
