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
