From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4587F5F9.7050906@domain.hid> Date: Tue, 19 Dec 2006 15:23:53 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 Subject: Re: [Adeos-main] Re: [RFC] git workflow References: <4582E67C.70108@domain.hid> <4587E99D.9070404@domain.hid> <4587ECF0.4000907@domain.hid> <4587EFE2.8040302@domain.hid> In-Reply-To: <4587EFE2.8040302@domain.hid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit List-Id: General discussion about Adeos List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: adeos-main Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > >>Jan Kiszka wrote: >> >>>Jan Kiszka wrote: >>> >>> >>>>... >>>>[Keeping up-to-date] >>>>1. The original kernel tree may have been updated, and the ipipe patch >>>> needs to be rebased >>>> >>>> # git fetch >>>> # git rebase origin >>> >>>I meanwhile learned that rebasing doesn't work well with public git >>>tree. Once you pushed some tree, say, linux-2.6.19 + ipipe-patch1..n >>>out, you cannot rebase to 2.6.20 + ipipe-patch1..n without breaking the >>>linear history. >>> >>>Either we only push out final trees (but that would lock-out early >>>testers that may want to pull from devel-head), or we need to evolve >>>with ipipe patches deeply merged. That means when we have 2.6.19 + ipipe >>>cleanly on top of it, pulling 2.6.20 origin may cause conflicts (like >>>the paravirt stuff does on i386 ATM). We would then have to merge the >>>upstream patches into the I-pipe tree, effectively adopting them to >>>I-pipe. An extraction of a potential I-pipe patch stack would be more >>>complicated that way, but not infeasible. >>> >>>Comments? >> >>I am a complete git newbie myself. But the simpler way I would imagine > > > Then I'm at least not alone. :) > > >>to develop the I-pipe would be to create one branch for each version of >>the kernel. We would then use a script to generate all architectures >>specific patches. >> >>Porting from one version to the next means merging the difference >>between the ipipe branch for linux 2.x.y and the linux 2.x.y sources >>with the linux-2.x.y+1 sources. > > > Of course, we could branch per major release and rebase on top of new > kernel versions. But that would mean we have to wait until the official > release to publish our trees. Otherwise, the risk would be the later > fixes require a rebase. Is it a big deal ? > > The point is likely how to extract ipipe stuff from a fully merged git > tree. I think this should not be that tricky - as long as every patch in > some series only touches existing files exclusively (i.e. no two patches > modify the same source file). Then we could simply apply some diff mask > (git diff origin..master file1 file2 file3...) to generate those > individual patches for reference to anyone willing to port stuff to a > new arch or board. Yes, what we need is something similar to "svn merge" functionality. -- Gilles Chanteperdrix