On 2013-01-15 20:39, Gilles Chanteperdrix wrote: > On 01/15/2013 02:58 PM, Philippe Gerum wrote: > >> On 01/15/2013 02:48 PM, Jan Kiszka wrote: >>> On 2013-01-15 14:44, Philippe Gerum wrote: >>>> On 01/15/2013 01:21 PM, Jan Kiszka wrote: >>>>> On 2013-01-15 13:09, Philippe Gerum wrote: >>>>>> On 01/15/2013 01:06 PM, Gilles Chanteperdrix wrote: >>>>>>> On 01/15/2013 12:35 PM, Jan Kiszka wrote: >>>>>>> >>>>>>>> On 2013-01-14 21:39, Gilles Chanteperdrix wrote: >>>>>>>>> Done, also note that my current work is the for-core-3.5.7 branch, not >>>>>>>>> the for-core-3.5 branch. >>>>>>>> >>>>>>>> Both branches point to the same commit ATM. I suppose you didn't push >>>>>>>> the new for-core-3.5.7 version yet. Once done, I'll rebase my stuff on >>>>>>>> top. >>>>>>> >>>>>>> >>>>>>> Sorry, pushed. >>>>>>> >>>>>> >>>>>> Please everybody, make sure to eventually resync with my tree, this is >>>>>> becoming a mess when merging your stuff here. TIA, >>>>> >>>>> I'm fetching from you regularly, but your public tree contains no >>>>> changes for 3.5, sorry. >>>>> >>>> >>>> You must mean no change for 3.5.3 since the last stable pipeline release >>>> I pushed out. I'm seeing several breakages when merging the very latest >>>> work, I'm solving this with Gilles. >>> >>> I mean that I have no clue what I should resolve. My branch was based on >>> your core-3.5 branch, the latest publicly available version. I've just >>> rebased it on top of Gilles' 3.5.7 queue - without any conflicts. So >>> what are you talking about? >>> >> >> I'm talking about conflicts in pgtable.h, apic.c with the atomic counter >> braindamage and stuff like this. I'm not asking you to fix anything in >> your tree, I'm pulling from Gilles' trees almost exclusively, and had >> issues with those. I raised an alert about painful merges happening >> lately, and a recommendation to avoid these. Gilles fixed the issue on >> his end, and the merge now resolves as a fast forward, as expected. >> Issue closed. > > > These were issues due to rebasing. Rebasings makes merging incrementally > harder, will avoid this in the future.
Rebasing is not bad per se and, where possible, better than leaving an un-bisectable commit series behind - IMHO. I suppose Philippe started pulling from your queue before you reordered/updated it again. That's why I didn't send out a pull request yet - mine wasn't done. I'm trying to formalize this process here, i.e. never rebase after releasing a queue for pulling. At the same time, upstream should not pull or pick in a way that makes life harder for downstream. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
