From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Cliff Brake <cliff.brake@gmail.com>
Cc: yocto@yoctoproject.org,
openembedded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: Multiple Repository support
Date: Wed, 22 Dec 2010 11:18:16 -0500 [thread overview]
Message-ID: <4D1224C8.7080100@windriver.com> (raw)
In-Reply-To: <AANLkTik3-5x2W+DRTJ9bC0YnUQB9HbvSWEYLSMWLTPjZ@mail.gmail.com>
On 10-12-22 11:09 AM, Cliff Brake wrote:
> Hello,
>
> I've started collecting ideas from various emails on multiple
> repository support.
>
> http://wiki.openembedded.org/index.php/MultipleRepositoryMethods
>
> Please feel free to update the above page.
>
> In my mind, this is a key problem we need to solve, not just for
> Yocto/OE, but also for anyone doing product development.
>
> I've personally been using git submodules for most projects, and repo
> for Android based projects.
>
> Appreciate any ideas, experiences, or insights into how we solve this problem.
We've used (and walked away) from git submodules in the
past for some really large projects. Our experiences closely
match "the bad" on the wiki link you sent. I've met very
few people who can effectively manage active development
in a git submodule based environment. My blunt opinion is
that if I never see another one in my life, I'd probably
be happy. I haven't looked at a submodule in about a year,
so maybe they have been fixed for the better .. but I'm
skeptical.
The solution to the submodule chaos that was used
sucessfully was to create something we called
'subgits'. They use git, a wrapper script and standard
git configs. A subgit points to a remote repo, specifies
where it should be cloned, and has a place for special
properties. You can recursively pull from a top level
and have all subgits updated in a uniform fashion. The
model can be extended for multi repository development
as well. The big win here is that you can independently
update repos, use normal git workflows, or wrap it as
you want. Nothing is forced.
Note: all the functionality of submodules isn't present
here (global tracking, bisect, etc), but that was functionality
that wasn't really crucial.
Just some comments and opinions to throw into the
discussion.
Cheers,
Bruce
>
> Thanks,
> Cliff
>
next prev parent reply other threads:[~2010-12-22 16:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 16:09 Multiple Repository support Cliff Brake
2010-12-22 16:18 ` Bruce Ashfield [this message]
2010-12-23 6:11 ` [yocto] " Esben Haabendal
2010-12-23 6:11 ` Esben Haabendal
2011-01-07 15:30 ` Vitus Jensen
2011-01-07 15:30 ` [oe] " Vitus Jensen
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=4D1224C8.7080100@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=cliff.brake@gmail.com \
--cc=openembedded-devel@lists.openembedded.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.