On 04/28/2011 01:28 AM, Richard Purdie wrote:
On Wed, 2011-04-27 at 20:59 -0400, Bruce Ashfield wrote:
On 11-04-27 6:47 PM, Darren Hart wrote:I think there are three elements to this:
I don't understand wanting to keep multiple distinct source trees in a singleThis is what I was wondering as well. I had my meta-kernel-dev as
git repositorie. If you have two different layers in there, each in its own
branch, then you can only work with one of them at a time. The end-user then has
to have multiple clones of the same repository in order to work with their two
layers. And they will end up naming them something like:
a branch on poky-extras and ran into exactly this problem. Either
have two clones, or get it into master. Master was the choice, since
the other seemed clunky.
Maybe I'm misunderstanding as well, but sparse fetch or not (and
yes I've done/used it), logically I like things that are distinct
source trees to be separate repos. Maybe it's a kernel-guy thing ? :)
a) People do like the logical separation that a repo gives them and
find it easiest to think in those terms.
b) Most people are used to single relatively monolithic repos such as
the kernel. People like myself who have used svn with multiple
projects contained within like matchbox or the OpenedHand "misc" svn
repo or the BSD projects approach to source control are probably in
c) The git tooling and all the examples out there are geared up to
single repos. git is very much a tool where you need to think as its
Some of this can be addressed with clear example documentation about how
to use git in this way.
Partly, these proposals are also working within the constraints of the
git server solution we have too. Are we really in such a bad position
that we need to change all the server setup over this or are there ways
we can work within the existing system (or even extend gitolite)?
I don't know what gitolite is capable of. I would really like to be able
to create and destroy my own repositories in a central location with
other Yocto developers.
However, this doesn't block me from moving forward. I can use kernel.org
or dvhart.com to do this for the time being and make requests of the
admins when I have a repository that looks to have some staying power.
I'll have to time this transition appropriately so that I don't have to
ask too many people to migrate to the new URL, but that would be true of
a personal repository to official repository move as well.
Intel Open Source Technology Center
Yocto Project - Linux Kernel