On Mon, 19 Nov 2007, Jon Smirl wrote:
> On 11/19/07, Catalin Marinas  wrote:

quoted text
> > "Jon Smirl"  wrote:

> > > On 11/18/07, Junio C Hamano  wrote:

> > >> "Jon Smirl"  writes:

> > >>

> > >> > What's causing this? I'm using stgit on the master branch.

> > [...]

> > >> pushed "A" to the remote's 'master', then built this history:

> > >>

> > >>          o---o---A

> > >>         /

> > >>     ---o---o---o---o---A'

> > >>

> > >> by rewinding and rebuilding, and the tip of the branch now

> > >> points at A', which you tried to push to the remote.

> > >

> > > stgit must be doing this when I rebase. It pops all of it's patches,

> > > moves to head of linus/master and then rebases them.

> > [...]

> > > What is the right way to share repositories using stgit? I have a set

> > > of patches which I am working on for kernel inclusion. I have them

> > > applied as a stgit stack on top of linus/master. I need to share this

> > > patch stack with other developers. These developers may want to change

> > > one of my patches. Right now they are emailing me deltas and I apply

> > > them to the appropriate stgit patch. I have seventeen patches in my

> > > stack currently.

> >

> > StGIT is meant for keeping a clean history but with the big

> > disadvantage that this history is volatile.

> >

> > A solution is for the other developers to use StGIT or just git-rebase

> > so that they always have the same base (volatile) history and keep

> > their patches on top of yours.

> >

> > A 2nd approach is to use topic branches rather than StGIT patches but

> > you might lose some flexibility.

> >

> > Yet another approach (which I used) is to keep a public branch (can be

> > maintained by StGIT) where the history doesn't change and a devel

> > volatile branch. When I modify some patches and they are ready for

> > publishing, switch to the public branch and cherry-pick them (stg

> > pick) from the devel branch. Because this is done with a three-way

> > merge in StGIT, you will only get the new changes rather than the full

> > patch. You need to change the patch message (as it is that of the

> > original patch) to describe the specific changes and run 'stg refresh

> > && stg commit' to store it into the immutable history (well, there is

> > an 'uncommit' command as well if something goes wrong).

>

>

> Is a StGit where we can transparently share patches under version

> control in the works?

>

> Something like this:

> clone repo with stgit

> normal stg commands work with no setup

> change a patch

> stg push the repo

>

> I stg pull and the patch is updated.

> I also get rebased forward if the base repo has been updated

I've been thinking vaguely about support for essentially version

controlling a quilt series, with the fundamental idea being that the

history of the branch you're working on is a sequence of states of the

series, with magic for having both the series specification and the final

state in each commit.
Note that this is a different concept from stgit (and, I think, guilt),

which uses the git engine as the magic behind the quilt-like operation,

meaning that the history of the commit at the end of the series goes back

through the patches in the series, not back through the changes to the

series.
I've got a bunch of ideas on the subject, but I don't really have the

quilt experience to know how to make this useful to people who want to do

this kind of thing. My dream, from the perspective of a user of the

results of somebody else's use of this feature, would be being able to

bisect -mm to determine first that -mm stopped working when Andrew updated

a particular tree, and then bisect within that tree (in each case

generating the test tree with the complete -mm series, but with that

tree's patch series being from the test point).
	-Daniel

*This .sig left intentionally blank*

-

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