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:

git remote add poky-contrib ssh://git@.../poky-contrib.git
git fetch poky-contrib tomz/foo:foo
git checkout foo

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.

Cheers,

Richard