# using stgit/guilt for public branches 12 messages from 2007-04-25 to 2007-05-04. Participants: Michael S. Tsirkin, Josef Sipek, Robin Rosenberg, Yann Dirson. Thread: https://gitlist.dev/t/7832 ## Michael S. Tsirkin, 2007-04-25 12:20 Subject: using stgit/guilt for public branches Message-ID: <20070425122048.GD1624@mellanox.co.il> URL: https://gitlist.dev/e/20070425122048.GD1624%40mellanox.co.il ``` 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? Thanks, -- MST ``` ## Josef Sipek, 2007-04-25 19:18 Subject: Re: using stgit/guilt for public branches Message-ID: <20070425191838.GA6267@filer.fsl.cs.sunysb.edu> URL: https://gitlist.dev/e/20070425191838.GA6267%40filer.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: > 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 ``` ## Michael S. Tsirkin, 2007-04-25 19:52 Subject: Re: using stgit/guilt for public branches Message-ID: <20070425195248.GA5217@mellanox.co.il> URL: https://gitlist.dev/e/20070425195248.GA5217%40mellanox.co.il In-Reply-To: <20070425191838.GA6267@filer.fsl.cs.sunysb.edu> ``` > Quoting Josef Sipek : > Subject: Re: using stgit/guilt for public branches > > You could try to use git to version the patches directory > (.git/patches/$branch/) and publish that in addition to the actual kernel > repository. How does one do this, exactly? -- MST ``` ## Josef Sipek, 2007-04-25 20:40 Subject: Re: using stgit/guilt for public branches Message-ID: <20070425204007.GA9375@filer.fsl.cs.sunysb.edu> URL: https://gitlist.dev/e/20070425204007.GA9375%40filer.fsl.cs.sunysb.edu In-Reply-To: <20070425195248.GA5217@mellanox.co.il> ``` On Wed, Apr 25, 2007 at 10:52:48PM +0300, Michael S. Tsirkin wrote: > > Quoting Josef Sipek : > > Subject: Re: using stgit/guilt for public branches > > > > You could try to use git to version the patches directory > > (.git/patches/$branch/) and publish that in addition to the actual kernel > > repository. > > How does one do this, exactly? cd .git/patches/$branch/ git-init-db git-commit -a -m "initial import" Then set up this repository to push/pull. No guarantees about it actually being helpful to your situation :) Josef "Jeff" Sipek. -- UNIX is user-friendly ... it's just selective about who it's friends are ``` ## Robin Rosenberg, 2007-04-25 21:37 Subject: Re: using stgit/guilt for public branches Message-ID: <200704252337.05851.robin.rosenberg.lists@dewire.com> URL: https://gitlist.dev/e/200704252337.05851.robin.rosenberg.lists%40dewire.com In-Reply-To: <20070425191838.GA6267@filer.fsl.cs.sunysb.edu> ``` 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. Patches your are done and not stored as patches anymore can be propagated to a "stable" branch using git branch -f stable HEAD~$(stg applied|wc -l) which is then pushed like any other branch. Don't play the stg uncommit game too much to avoid a mess. I'm not sure the branch command is the best way, but you get the idea. -- robin ``` ## Yann Dirson, 2007-05-03 20:58 Subject: Re: using stgit/guilt for public branches Message-ID: <20070503205836.GA19253@nan92-1-81-57-214-146.fbx.proxad.net> URL: https://gitlist.dev/e/20070503205836.GA19253%40nan92-1-81-57-214-146.fbx.proxad.net In-Reply-To: <200704252337.05851.robin.rosenberg.lists@dewire.com> ``` 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. The next stgit release will allow you to declare the pull-policy for your stack as "rebase", so when you "stg pull" it will indeed rebase to the new tip of the parent branch. As for publishing, I use the following config entries to publish my own stack of patches to stgit. You can see at http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly the structure of the stack (even though things could surely be made better). I use "git push -f" to publish - maybe the "+" refspec syntax would work with push, I'll try it next time :) [remote "orcz"] url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git push = refs/heads/master:refs/heads/master push = refs/patches/master/*:refs/patches/master/* Maybe we should provide some degree of automation in stgit itself (eg. "stg branch --publish" or something). Hope this helps, -- Yann. ``` ## Robin Rosenberg, 2007-05-03 23:10 Subject: Re: using stgit/guilt for public branches Message-ID: <200705040110.34697.robin.rosenberg.lists@dewire.com> URL: https://gitlist.dev/e/200705040110.34697.robin.rosenberg.lists%40dewire.com In-Reply-To: <20070503205836.GA19253@nan92-1-81-57-214-146.fbx.proxad.net> ``` torsdag 03 maj 2007 skrev Yann Dirson: [...] > As for publishing, I use the following config entries to publish my > own stack of patches to stgit. You can see at > http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly > the structure of the stack (even though things could surely be made > better). > > I use "git push -f" to publish - maybe the "+" refspec syntax would > work with push, I'll try it next time :) > > [remote "orcz"] > url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git > push = refs/heads/master:refs/heads/master > push = refs/patches/master/*:refs/patches/master/* Beautiful!! I needed to change the update commit though for git to recognize the refs/patches heads. Or is that only because I had initialized the repos using v1.5.0 ? -- robin ``` ## Robin Rosenberg, 2007-05-03 23:31 Subject: Re: using stgit/guilt for public branches Message-ID: <200705040131.17837.robin.rosenberg.lists@dewire.com> URL: https://gitlist.dev/e/200705040131.17837.robin.rosenberg.lists%40dewire.com In-Reply-To: <200705040110.34697.robin.rosenberg.lists@dewire.com> ``` fredag 04 maj 2007 skrev Robin Rosenberg: > torsdag 03 maj 2007 skrev Yann Dirson: > [...] > > As for publishing, I use the following config entries to publish my > > own stack of patches to stgit. You can see at > > http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly > > the structure of the stack (even though things could surely be made > > better). > > > > I use "git push -f" to publish - maybe the "+" refspec syntax would > > work with push, I'll try it next time :) > > > > [remote "orcz"] > > url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git > > push = refs/heads/master:refs/heads/master > > push = refs/patches/master/*:refs/patches/master/* > > Beautiful!! > Would it be possible to push only applied patches, and drop unapplied ones? It would only matter when one wants to prune the remote repo so it may not be terribly important, but it seems I pushed quite a lot of references from old patches that I haven't decided what to do with yet and those will get new commit id's anyway. -- robin ``` ## Michael S. Tsirkin, 2007-05-04 05:20 Subject: Re: using stgit/guilt for public branches Message-ID: <20070504052042.GA4829@mellanox.co.il> URL: https://gitlist.dev/e/20070504052042.GA4829%40mellanox.co.il In-Reply-To: <20070503205836.GA19253@nan92-1-81-57-214-146.fbx.proxad.net> ``` > Quoting Yann Dirson : > 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? -- MST ``` ## Yann Dirson, 2007-05-04 21:28 Subject: Re: using stgit/guilt for public branches Message-ID: <20070504212842.GB19253@nan92-1-81-57-214-146.fbx.proxad.net> URL: https://gitlist.dev/e/20070504212842.GB19253%40nan92-1-81-57-214-146.fbx.proxad.net In-Reply-To: <200705040131.17837.robin.rosenberg.lists@dewire.com> ``` On Fri, May 04, 2007 at 01:31:17AM +0200, Robin Rosenberg wrote: > fredag 04 maj 2007 skrev Robin Rosenberg: > > torsdag 03 maj 2007 skrev Yann Dirson: > > [...] > > > As for publishing, I use the following config entries to publish my > > > own stack of patches to stgit. You can see at > > > http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly > > > the structure of the stack (even though things could surely be made > > > better). > > > > > > I use "git push -f" to publish - maybe the "+" refspec syntax would > > > work with push, I'll try it next time :) > > > > > > [remote "orcz"] > > > url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git > > > push = refs/heads/master:refs/heads/master > > > push = refs/patches/master/*:refs/patches/master/* > > > > Beautiful!! > > > Would it be possible to push only applied patches, and drop unapplied > ones? This would require stgit-level knowledge, so we would need an stgit command. Maybe "stg publish" or "stg branch --publish" with the current syntax, since we already have "push". I'd be in favor of "stg branch push" for the next-gen syntax, though ;) > It would only matter when one wants to prune the remote repo > so it may not be terribly important, but it seems I pushed quite a > lot of references from old patches that I haven't decided what to do > with yet and those will get new commit id's anyway. For now you can delete them manually with "git push remote/ref:". Best regards, -- Yann. ``` ## Yann Dirson, 2007-05-04 21:37 Subject: Re: using stgit/guilt for public branches Message-ID: <20070504213741.GC19253@nan92-1-81-57-214-146.fbx.proxad.net> URL: https://gitlist.dev/e/20070504213741.GC19253%40nan92-1-81-57-214-146.fbx.proxad.net In-Reply-To: <20070504052042.GA4829@mellanox.co.il> ``` On Fri, May 04, 2007 at 08:20:59AM +0300, Michael S. Tsirkin wrote: > > Quoting Yann Dirson : > > 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. ``` ## Yann Dirson, 2007-05-04 23:12 Subject: Re: using stgit/guilt for public branches Message-ID: <20070504231225.GD19253@nan92-1-81-57-214-146.fbx.proxad.net> URL: https://gitlist.dev/e/20070504231225.GD19253%40nan92-1-81-57-214-146.fbx.proxad.net In-Reply-To: <20070503205836.GA19253@nan92-1-81-57-214-146.fbx.proxad.net> ``` On Thu, May 03, 2007 at 10:58:36PM +0200, Yann Dirson wrote: > As for publishing, I use the following config entries to publish my > own stack of patches to stgit. You can see at > http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly > the structure of the stack (even though things could surely be made > better). Let's make things even more fun: I have now moved a couple of patches (testsuite cases to demonstrate bugs still to be fixed) to a new stack so they don't get pulled by error. This stack itself is forked off my master stack, and I just have to "stg pull" to get it rebased to the new master head (requires stgit head, not in 0.12*): [branch "bugs.stgit"] pull-policy = rebase parentbranch = master > I use "git push -f" to publish - maybe the "+" refspec syntax would > work with push, I'll try it next time :) It indeed works as expected, so the final syntax is as follows, so "git push orcz" is now sufficient to publish everything, and you can now fork your own stack off my remote "bugs" stack, which itself forked off my "master" stack - enjoy :) [remote "orcz"] url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git fetch = +refs/heads/*:refs/remotes/orcz/* push = +refs/heads/master:refs/heads/master push = +refs/patches/master/*:refs/patches/master/* push = +refs/heads/bugs:refs/heads/bugs push = +refs/patches/bugs/*:refs/patches/bugs/* Best regards, -- Yann. ```