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.ashfield@...> 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://git@.../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@...
https://lists.yoctoproject.org/listinfo/yocto