From: Avery Pennarun <apenwarr@gmail.com>
To: git@eisendle.net
Cc: git@vger.kernel.org
Subject: Re: Linux Kernel based project in git
Date: Tue, 2 Feb 2010 14:53:13 -0500 [thread overview]
Message-ID: <32541b131002021153t53d19e32j56be356c219c5780@mail.gmail.com> (raw)
In-Reply-To: <9da7f2802f639777acfeb38eb1e3db90.squirrel@webmail.eisendle.net>
On Tue, Feb 2, 2010 at 4:05 AM, <git@eisendle.net> wrote:
> For release we always generate 3 patches:
> - BSP patch
> - USB patch (since USB part is an external patch comming from a 3rd party)
> - WiFi patch (same as for USB)
>
> So my question is:
> What's the best way for handling this inside the git repository?
>
> IMHO it would make sense to have 3 branches (BSP, USB, WiFi) each based on
> unmodified 2.6.22 Kernel. USB and WiFi branch is used for generating the
> patch and for applying possible fixes. BSP branch for actual BSP related
> feature development and fixes.
> The changes in these branches are merged into the master branch which is
> used for compiling/testing the whole BSP.
Are you planning to submit these patches upstream at any point? If
not, it might be easiest to just jam them all together in one branch
and not look back. Since it seems like they probably affect quite
different parts of the code, you could always extract a clean set of
patches *later* and submit those patches upstream.
But that's just my lazy advice :) The disadvantage to maintaining
them in separate branches is that probably none of the three branches
will work on its own anyway, since you don't have a physical device
that only has the new USB device, or only the new WiFi device, or only
needs the BSP but doesn't have updated USB or WiFi. Putting them in
separate branches is therefore a bit artificial and won't buy you
much.
Have fun,
Avery
next prev parent reply other threads:[~2010-02-02 19:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-02 9:05 Linux Kernel based project in git git
2010-02-02 19:53 ` Avery Pennarun [this message]
2010-02-03 8:32 ` Christian Eisendle
2010-02-06 11:43 ` Stephen Kelly
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=32541b131002021153t53d19e32j56be356c219c5780@mail.gmail.com \
--to=apenwarr@gmail.com \
--cc=git@eisendle.net \
--cc=git@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).