[yocto] Personal git repositories

[Bruce Ashfield]

On 11-04-28 04: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 don't understand wanting to keep multiple distinct source trees in a single
>>> 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:
>>>
>>> yocto-contrib-layer-1.git
>>> yocto-contrib-layer-2.git
>>
>> This is what I was wondering as well. I had my meta-kernel-dev as
>> 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 ? :)
>
> I think there are three elements to this:
>
> 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
>     the minority.
> 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
>     authors do.

Agreed with the points above. git really is just wrangling a bunch
of objects into commit chains and a branch points to a starting
point. So I completely agree that all chains don't have to lead to
the same origin, like you said, it is just how people tend to think.

>
> 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

I think we are likely ok, people have solutions that work, getting
the right contrib repos setup with appropriate permissions to setup
branches will go a long way.

As long as things stay responsive, I'd imagine that we'll find
that people will be happy with things as they are. At least we've
considered the options before it is critical.

Cheers,

Bruce

> we can work within the existing system (or even extend gitolite)?
>
> Cheers,
>
> Richard
>
>
>