All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <darren.hart@intel.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: Personal git repositories
Date: Thu, 28 Apr 2011 10:07:09 -0700	[thread overview]
Message-ID: <4DB99EBD.8040207@intel.com> (raw)
In-Reply-To: <1303979316.21461.29.camel@rex>

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


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

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


  parent reply	other threads:[~2011-04-28 17:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27  3:00 Personal git repositories Darren Hart
2011-04-27  3:22 ` Bruce Ashfield
2011-04-27  3:57   ` Darren Hart
2011-04-27  4:37     ` Saul Wold
2011-04-27  4:56       ` Darren Hart
2011-04-27  4:39 ` Tom Zanussi
2011-04-27  4:53   ` Darren Hart
2011-04-27  5:05     ` Tom Zanussi
2011-04-27  6:35       ` Darren Hart
2011-04-27  7:56 ` Koen Kooi
2011-04-27 14:45   ` Darren Hart
2011-04-27 17:20     ` Elizabeth Flanagan
2011-04-27 18:14       ` Joshua Lock
2011-04-27 18:29         ` Elizabeth Flanagan
2011-04-27 21:03       ` Richard Purdie
2011-04-27 22:47         ` Darren Hart
2011-04-28  0:59           ` Bruce Ashfield
2011-04-28  3:12             ` Xianghua Xiao
2011-04-28  8:28             ` Richard Purdie
2011-04-28 14:56               ` Bruce Ashfield
2011-04-28 17:07               ` Darren Hart [this message]
2011-04-29  4:04           ` Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DB99EBD.8040207@intel.com \
    --to=darren.hart@intel.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.