Re: Personal git repositories

[Darren Hart <darren.hart@intel.com>]

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

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?

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