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
--

Jon Smirl

jonsmirl@gmail.com

-

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