From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5214A886.30608@siemens.com> Date: Wed, 21 Aug 2013 13:46:14 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <52147CD7.70400@siemens.com> <52147DF2.8060407@xenomai.org> <52147E94.6070309@siemens.com> <5214802B.9060001@siemens.com> <5214A55E.2070902@xenomai.org> In-Reply-To: <5214A55E.2070902@xenomai.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] [RFC] x86 port to kernel 3.10 List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Xenomai On 2013-08-21 13:32, Gilles Chanteperdrix wrote: > On 08/21/2013 10:54 AM, Jan Kiszka wrote: >> On 2013-08-21 10:47, Jan Kiszka wrote: >>> On 2013-08-21 10:44, Gilles Chanteperdrix wrote: >>>> On 08/21/2013 10:39 AM, Jan Kiszka wrote: >>>>> Hi all, >>>>> >>>>> in the process of updating our kernel support to current (and long-term) >>>>> stable 3.10, I've pushed the I-pipe master tree to that version. The >>>>> tree is available at >>>>> >>>>> git://git.xenomai.org/ipipe-jki.git next-x86 >>>>> >>>>> Though the focus is on x86, this became a full merge, ie. I also tried >>>>> to resolve ARM and PowerPC conflicts (other archs had none). But I'm >>>>> sure I broke some things (or things were already broken after the 3.9 >>>>> merge - there were suspicious unresolved conflicts). So these arch need >>>>> a careful check! Specifically watch out for merges that resolved >>>>> conflicts in their trees. >>>>> >>>> >>>> I would prefer to have the conflict markers in the git tree, so that we >>>> know where the conflicts occur. Having to browse history to find all the >>>> merge conflicts seems more complicated than greping for '>>>'. Of >>>> course, it means that when all the conflicts are resolved, the kernel >>>> should be rebased to remove the commits with the merge conflicts, so as >>>> to keep a bisectable kernel. >>> >>> As you cannot rebase merges (without losing history), this is not really >>> applicable. I can leave in conflicts that affect ARM or Power, sure, but >>> then the fix-ups will have to happen on top, taking away bisectability. >> >> Hmm, what we would really need is some tool to replay merges with their >> conflict resolution. That must be feasible, somehow... > > You mean like git rerere? Anyway, why not just one big commit with all > the conflicts? For the reason given in my original message. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux