Re: using stgit/guilt for public branches
- From
- Josef Sipek <jsipek@fsl.cs.sunysb.edu>
- Date
- Apr 25, 2007, 19:18 UTC
- Message-ID
- <20070425191838.GA6267@filer.fsl.cs.sunysb.edu>
- In-Reply-To
- <20070425122048.GD1624@mellanox.co.il>
On Wed, Apr 25, 2007 at 03:20:49PM +0300, Michael S. Tsirkin wrote:
Show 17 quoted lines
> Hi! > On git.openfabrics.org we use git to manage all code for our OFED distribution. > For our kernel code we basically started with 2.6.20, and add some patches, > which we currently keep separate from upstream kernel source - this makes > it possible to update from upstream and extract the patches to post > them for upstream inclusion easily. > > On the surface, it looks like using stg or guilt would be a good idea for us, > however multiple people need to collaborate on the patch series. > > I am concerned that publishing a git branch managed by stg/guilt > would present problems: it seems that every time patches are re-ordered, > a patch is re-written or removed, or we update from upstream, > everyone who pulls the tree branch will have a hard-to-resolve conflict. > > Is that really a problem? If so, would it be possible to work around this > somehow?
I thought about this problem a while back when I was trying to decide how to manage the Unionfs git repository. I came to the conclusion, that there was no clean way of doing this (at least not using guilt - I can't really speak for stgit, as I don't know how it does things exactly).
You could try to use git to version the patches directory (.git/patches/$branch/) and publish that in addition to the actual kernel repository.
Josef "Jeff" Sipek.
-- Keyboard not found! Press F1 to enter Setup