[ofa-general] Fwd: Re: using stgit/guilt for public branches

[Michael S. Tsirkin]

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 <ydirson at altern.org> -----

Subject: Re: using stgit/guilt for public branches
Date: Sat, 5 May 2007 00:37:41 +0300
In-Reply-To: <20070504052042.GA4829 at mellanox.co.il>
References: <20070425122048.GD1624 at mellanox.co.il> <20070425191838.GA6267 at filer.fsl.cs.sunysb.edu> <200704252337.05851.robin.rosenberg.lists at dewire.com> <20070503205836.GA19253 at nan92-1-81-57-214-146.fbx.proxad.net> <20070504052042.GA4829 at mellanox.co.il>
From: Yann Dirson <ydirson at altern.org>

On Fri, May 04, 2007 at 08:20:59AM +0300, Michael S. Tsirkin wrote:
> > Quoting Yann Dirson <ydirson at altern.org>:
> > 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 majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

----- End forwarded message -----

-- 
MST