> Quoting Yann Dirson <ydirson@altern.org>:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html