git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Git setup for kernel in-house development + mainstream submissions?
@ 2009-02-01 21:25 PaV
  2009-02-02  7:26 ` Johannes Gilger
  2009-02-03  4:13 ` Matt Graham
  0 siblings, 2 replies; 3+ messages in thread
From: PaV @ 2009-02-01 21:25 UTC (permalink / raw)
  To: git

Hello,

I would like to kindly ask for suggestions how to setup and use git in a
company that performs in-house kernel development (drivers mostly) for
its own devices and would like to occasionaly submit patches for mainstream.

I've come up with a short list of use cases/requirements (possibly not
exhaustive, any suggestions here as well please?):

1) a way to separate development of in-house code (various drivers)

2) a place to merge everything done in-house and provide current
development snapshot for internal use

3) something that tracks the current mainstream tree, to be merged with
(3) ocassionaly (or (2)?)

4) a simple way to select changes (which may be as small as only parts
of any of the drivers), format them and submit for upstream merge.
Preferably, if possible, prepare those series of patches and store them
for later use (immediate submission might not be possible and might not
be done at all).

5) (more?)


So the proposed setup might be:
(1) - in-house devel could be done on separate branches for each driver
(2) - a master branch (on the main server) for in-house snapshots and
distribution
(3) - a separate tracking branch for mainstream
(4) - now this is hard.
The main problems are how to create, how to diff and how to manage those
patches (stgit?) and what to do when mainstream gets updated, etc...

So ideas are: rebase and/or stgit/quilt. Or/and maybe topic branches,
creating new branches for each new kernel version for each driver,
copying the old branch and rebasing?
This is the most important part for which I'd like to ask for suggestions...

Any other suggestions are of course also welcome, my experience in git
is small and I might have missed things.

Thank you!
Paul

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Git setup for kernel in-house development + mainstream submissions?
  2009-02-01 21:25 Git setup for kernel in-house development + mainstream submissions? PaV
@ 2009-02-02  7:26 ` Johannes Gilger
  2009-02-03  4:13 ` Matt Graham
  1 sibling, 0 replies; 3+ messages in thread
From: Johannes Gilger @ 2009-02-02  7:26 UTC (permalink / raw)
  To: git

On 2009-02-01, PaV <pav@aster.pl> wrote:
> I would like to kindly ask for suggestions how to setup and use git in a
> company that performs in-house kernel development (drivers mostly) for
> its own devices and would like to occasionaly submit patches for mainstream.
> [...]
> So the proposed setup might be:
> (1) - in-house devel could be done on separate branches for each driver

Do you really want to have separate drivers in the same git repository? 
Do these drivers share so much code and depend on each other that this 
would be necessary? If not I'd suggest you think about separate git 
projects for each driver, unless there is a compelling reason against 
it.

Greetings,
Jojo

-- 
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81  882C 58EE B178 42F6 DE81

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Git setup for kernel in-house development + mainstream  submissions?
  2009-02-01 21:25 Git setup for kernel in-house development + mainstream submissions? PaV
  2009-02-02  7:26 ` Johannes Gilger
@ 2009-02-03  4:13 ` Matt Graham
  1 sibling, 0 replies; 3+ messages in thread
From: Matt Graham @ 2009-02-03  4:13 UTC (permalink / raw)
  To: PaV; +Cc: git

On Sun, Feb 1, 2009 at 16:25, PaV <pav@aster.pl> wrote:
> I would like to kindly ask for suggestions how to setup and use git in a
> company that performs in-house kernel development (drivers mostly) for
> its own devices and would like to occasionaly submit patches for mainstream.
>
> 4) a simple way to select changes (which may be as small as only parts
> of any of the drivers), format them and submit for upstream merge.
> Preferably, if possible, prepare those series of patches and store them
> for later use (immediate submission might not be possible and might not
> be done at all).
>
> (4) - now this is hard.
> The main problems are how to create, how to diff and how to manage those
> patches (stgit?) and what to do when mainstream gets updated, etc...

When you decide what to prepare for an upstream merge, it sounds like
what you'd want to do is make a new "upstream" branch and cherry pick
the changes you want onto it.  You can use git cherry-pick -n to clean
them up or squash them together if necessary.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-02-03  4:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-01 21:25 Git setup for kernel in-house development + mainstream submissions? PaV
2009-02-02  7:26 ` Johannes Gilger
2009-02-03  4:13 ` Matt Graham

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).