Re: [Adeos-main] Re: [RFC] git workflow

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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