Proposal for further openmoko kernel development

Lars-Peter Clausen lars at metafoo.de
Wed Jul 29 12:24:34 CEST 2009


Stefan Schmidt wrote:
> Hello.
>
> On Wed, 2009-07-29 at 01:49, Lars-Peter Clausen wrote:
>   
>> Werner Almesberger wrote:
>>     
>>> Lars-Peter Clausen wrote:
>>>
>>> Hmm, this sounds like a lot of trees with a lot of merging going
>>> on between them.
>>>       
>> Well, depends on your definition of 'a lot'. We would probably end
>> up with ~10 driver trees + 3 machine trees + 1 all tree = ~ 15
>> trees.
>>     
>
> May I ask you why you want to use complete trees for the split instead of
> branches? What are you talking about here sounds a lot like topic branches to
> me. A branch in your tree to work on a special feature/topic. You want a
> patchstack like in quilt but using git features for it.
>
> We tried stgit and guilt for exactly this setup at OpenEZX. Both failed due to
> being useable for one person only, not a team. Then we found topgit and went
> happy. :)
>
> Topgit offers topic branches with interdependencies and the metadata available
> for all team members in the git repo. Do a tg patch export in one topic branch
> and you get all commits in this branch merged together in one nice clean patch.
> Like quilt but this time with version control as well. :)
>
> http://repo.or.cz/w/topgit.git?a=blob;f=README
>   
Yep, topgit pretty much looks like what I was looking for. I want to 
keep track of set of related patches in a bigger tree.
>   
>> Ok, compared to 1 tree, as we have now, but you have to consider
>> that the more drivers get merged upstream the less trees we'll need.
>> And my proposed structure makes upstream inclusion a lot easier
>> since you always have all changes to get a driver support in a
>> single patchset. Instead of having to pick it from the huge series
>> of patches which contain everything.
>>
>> Merging will only take place in on direction. The all-tree merges
>> gta01 and gta02. The machine trees merge driver tree. But driver
>> trees don't merge driver trees, as those should be independent to
>> each other.
>>     
>
> Life is not that easy normally. How would you like to test your driver in the
> special driver tree? Say it does not depend on another driver, which happens
> more often then people like. You still need the machine file and maybe some
> platform data. From your description this is in another tree which should never
> be merged into the "low-level" driver tree.
>   
As I said in my first post, one would not develop in the driver trees. 
One would develop in a machine tree and then rebase the commits onto the 
driver tree.
But I guess when using topgit this won't be necessary anymore, as it can 
keep track of the driver patches inside the machine tree.
>   
>>> Do you mean "rebase" like in git-rebase ? If I understand things
>>> correctly, this makes it impossible to run a local tree off the
>>> tree that's being rebased. So the tree that's constantly being
>>> rebased would have to be a leaf.
>>>       
>> Yes, rebase as in git-rebase. At each major upstream release one
>> would create a new branch from the current one and then rebase the
>> new branch onto the new upstream kernel. Another possibility would
>> be to merge upstream into the current branch. But I prefer to
>> rebase, because it makes it a lot easier to keep a clean patch set.
>>     
>
> You really should avoid rebasing branches that are available public. It breaks a
> lot for people that are trying to work with you in such a branch. Ask werner
> about the problems he had with andy-trackinf being rebased all the time. (It
> came from the fact that Andy did use stgit which worked well for him that way,
> but not for others who did not have the stgit metadata). Rebasing should be a
> local-only operation.
>   
I don't want to rebase public branches. What I want to do is to create a 
new branch starting at the current branch and then rebase the new 
upstream. As in:
git checkout gta02-2.6.30 -b gta02-2.6.31
git rebase v2.6.30 HEAD --onto v2.6.31

- Lars



More information about the openmoko-kernel mailing list