Gilles Chanteperdrix wrote: > 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 ?
Once there is a public tree with 2.6.20-rc1 + ipipe + -rc2, you cannot simply turn that tree into 2.6.20-rc1 + -rc2 + ipipe. The order of patches is practically frozen once published. In your private tree you are, of course, free to do this and then extract some patch to post upstream. > >> 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. > That's integrated in git-pull. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
