FYI. I posted a question on git mailing list, asking about
best ways to manage ofed repository.

http://article.gmane.org/gmane.comp.version-control.git/45519

The conclusion so far seems to be that what we are doing (keeping patches
under version control) is basically the right way to do it:

http://article.gmane.org/gmane.comp.version-control.git/45569

-- 
MST
--- Begin Message ---
On Wed, Apr 25, 2007 at 03:20:49PM +0300, Michael S. Tsirkin wrote:
> 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

--- End Message ---
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to