On 01/26/2012 05:45 PM, Jan Kiszka wrote: > > > >> I merged the upstream patches one by one, resolving the mechanical and > >> logical conflicts in each step. Was done for that backend/frontend > >> concept, but the adjustments should basically be the same now. Want me > >> to prepare a branch or will you do this? > > > > It's much more likely that you'll get it right - I started to do this > > but backed out. > > > > btw, the branch doesn't appear to be merges, so I'll still have huge > > conflicts at the end. If you do this with real merges, git will > > recognize it and just adopt your version. > > I will try to use your concept: pull in upstream commits into a merge > branch as long as there is a mechanical or logical conflict. That's what I do in my upstream merges. I use bisect to find the first conflict, but in this case I imagine there will be a conflict in every merge except the memory.c one. > Will then > publish the branch for pulling. Can I start at the current 'next' head? Yes please. It's halfway through autotest and looks good. Even if I have to change it, we can 'git rebase -p --onto' your branch (though I doubt it will be necessary). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
