[ofa-general] Fwd: Re: using stgit/guilt for public branches
FYI, some more discussion forwarded from the git mailing list. Executive summary: it's possible to make repostitory managed by stgit public, but tools to make it possible for multiple developers to clone and work on such a repository seem not to be there yet. - Forwarded message from Yann Dirson <[EMAIL PROTECTED]> - Subject: Re: using stgit/guilt for public branches Date: Sat, 5 May 2007 00:37:41 +0300 In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> From: Yann Dirson <[EMAIL PROTECTED]> On Fri, May 04, 2007 at 08:20:59AM +0300, Michael S. Tsirkin wrote: > > Quoting Yann Dirson <[EMAIL PROTECTED]>: > > Subject: Re: using stgit/guilt for public branches > > > > On Wed, Apr 25, 2007 at 11:37:05PM +0200, Robin Rosenberg wrote: > > > onsdag 25 april 2007 skrev Josef Sipek: > > > > On Wed, Apr 25, 2007 at 03:20:49PM +0300, Michael S. Tsirkin wrote: > > > [...] > > > > > 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). > > > > > > StGit has the same problem. Publishing such a branch is only for viewing > > > if > > > you want to publish the tip, like the pu branch in the Git repo. You > > > shouldn't > > > merge from pu either. > > > > You are right, in that what can be done with such branches is limited. > > BUT you can safely "stg branch --create" off any remote stgit stack. > > Then you can "stg rebase origin/master" to port your stack to the new > > tip of the remote stack. > > OK. > What happens if someone clones the repo, then reorders patches, > drops some of them, adds new patches in the middle of the stack? You can't do that out of the box, since you don't get a real stack when you clone it, you only get the refs. You would need to uncommit patches manually, and there will not be much support to help you. Now you're forcing me to unveil my secret plans :) 1. it would be quite easy to reconstruct a full-fledged stack from those refs, and since you get the remote patchlogs, we could also fetch any former version of the patch that would be still available (more work for "stg clone") 2. if noone beats me to doing that, I'll enhance patchlogs some day to record branching in patchlogs (eg. from "stg branch --clone" or "stg pick"), as well as merges (eg. from "stg sync") Note that proper merging from patchlog history will require working at the meta-diff (ie. "diffs of diffs of trees") level, just like proper merging at tree-level requires working at the diff level. I don't think we have the tools for this yet, so we still have a long way to go :) Best regards, -- Yann. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - End forwarded message - -- MST ___ 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
Re: [ofa-general] Fwd: Re: using stgit/guilt for public branches
> Quoting Sean Hefty <[EMAIL PROTECTED]>: > Subject: RE: [ofa-general] Fwd: Re: using stgit/guilt for public branches > > >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 > > I strongly prefer that the patches be applied to the actual code. It looks nice on the surface, but won't work well in practice I'm afraid. There's only one way to get close to this - agree that OFED, as a rule, should not include code that is not upstream on kernel.org (we could add out of kernel modules without touching core, but that would be all). I would be fine with this rule, but would you? > Someone who wants to use stgit can generate their own set of patches and > manage them off the tree if they want. This managing of two parallel trees would fall on the shoulders of OFED maintainers, and I don't think it's practical to keep it up in parallel with OFED integration which is also a full time job. > Right now it's way too difficult to see what code is there, How is it difficult? "What code is there" is not well-defined, since it actually depends on the distro. For a specific distro - get the tarball, run ./configure, and look. > switch 'branches', What does this mean? Do you want to branch off ofed 1.2? git-branch and off you go - build scripts *already* can get a branch name. Again, what's so difficult? > generate patches, Did you read the howto's? it's *really* easy to do using quilt, I do it all the time: quilt new foo.patch quilt add quilt refresh > etc. I have to ask - did you read the actual thread? You seem to ignore all arguments why using stg won't work for a public tree. In this thread, git guys told us keeping patches under git as we already do seems to be the best option available option. > We're doing everything manually and losing the majority > of the benefits that git gives us. This is clearly not true. We are pulling code from multiple people completely automatically by git pull. We have a build system that can be pointed at any git tree and will generate a tarball from there. There's a hash based checksum that identifies each build in a unique way. All these are main benefits of git. And while git does not include tools to apply patches for you, patches are also applied by quilt, not manually. So - What is done manually? What benefits did we lose? -- MST ___ 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
RE: [ofa-general] Fwd: Re: using stgit/guilt for public branches
>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 I strongly prefer that the patches be applied to the actual code. Someone who wants to use stgit can generate their own set of patches and manage them off the tree if they want. Right now it's way too difficult to see what code is there, switch 'branches', generate patches, etc. We're doing everything manually and losing the majority of the benefits that git gives us. - Sean ___ 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
[ofa-general] Fwd: Re: using stgit/guilt for public branches
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
