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@xxxxxxxxxx/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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html