most if not all meego repo is on gitorious, why can't Yocto leverage
it, at least for now while everything is changing fast?

Xianghua

On Wed, Apr 27, 2011 at 7:59 PM, Bruce Ashfield
<bruce.ashfi...@windriver.com> wrote:
> On 11-04-27 6:47 PM, Darren Hart wrote:
>>
>> On 04/27/2011 02:03 PM, Richard Purdie wrote:
>>>
>>> On Wed, 2011-04-27 at 10:20 -0700, Elizabeth Flanagan wrote:
>>>>
>>>> A few notes, since I talked with Darren about this earlier.
>>>>
>>>> As one of the people in charge of maintaining the git repo, I would like
>>>> to
>>>> avoid having, as Darren suggested, a whole bunch of -contrib repos.
>>>> However,
>>>> maybe I'm missing something here, as I think basic git solves this
>>>> issue:
>>>>
>>>> Use Case: Tomz has a branch of meta-intel that he has pushed to
>>>> poky-contrib.git:tomz/foo. dvhart wants to look at it from his local
>>>> repo:
>>
>> I'm curious how many people reading this feel this is "basic git". Anyone
>> willing to admit this was the first time they have seen a targeted branch
>> fetch used to avoid a larger download? If everyone is comfortable with
>> this,
>> fine. If not, we should consider the impact of this type of access on our
>> users.
>>
>>>> git remote add poky-contrib ssh://g...@git.pokylinux.org/poky-contrib.git
>>>> git fetch poky-contrib tomz/foo:foo
>>>> git checkout foo
>>
>> My biggest complaint with this is the lack of self discovery from within
>> git
>> without doing a git remote update. Unless tomz is online at the time to
>> tell me
>> it's tomz/foo-bar, not tomz/foo_bar, then I have to go load the web
>> browser and
>> check which branches are available, or resort to downloading all the
>> objects.
>>
>>
>> I confess though, it still just feels wrong to keep unrelated source trees
>> in
>> the same repository.
>>
>>>>
>>>> The fetch allows a sparse checkout of *just* tomz's branch. No need to
>>>> download all 75M of poky-contrib which is what you would do with "git
>>>> remote
>>>> update". Git remote update is the wrong way to do this and I'd like to
>>>> avoid
>>>> having to swap infrastructure around when it seems to me that this is
>>>> just
>>>> one of those "git being a pain to learn"
>>>
>>> Just to add to this discussion, with gitolite, it should be easy to
>>> setup a yocto-contrib repo where each user "owns" the branches under
>>> <keyname>/*. This means as ssh keys are added, they'd automatically get
>>> their own "scratch" area. As Beth points out above, its perfectly
>>> possible to checkout branches and manipulate them as long as you know
>>> the commands.
>>>
>>> This isn't a set of repos per user but when you think about this, how
>>> often do we really need that? Yes, some people like Bruce have usecases
>>> but I'm not sure they're typical and in those small number of cases I'm
>>> sure we can come up with some generic testing/dev repos to assist too.
>>> As soon as something grows to the point where the branch is problematic,
>>> it deserves its own repo and it should be properly namespaced, not user
>>> specific anyway.
>>
>>
>> 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 ? :)
>
> Cheers,
>
> Bruce
>
>>
>> And keep them checked out to the appropriate set of branches... that seems
>> like
>> a lot of pain to impose on users to avoid setting up personal git
>> repositories.
>> Personally, I think I would revert to my kernel.org repositories rather
>> than try
>> and make this work.
>>
>> Or - is my git-fu weak? Is there a better way to handle the above?
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to