> Quoting Yann Dirson <ydirson@xxxxxxxxxx>: > 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 - 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