Re: ! [rejected] master -> master (non-fast forward)

> "Jon Smirl" <jonsmirl@gmail.com> wrote:
> > On 11/18/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> "Jon Smirl" <jonsmirl@gmail.com> 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).