"Jon Smirl" <jonsmirl@gmail.com> wrote:
quoted text
> 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.
[...]
quoted text
>> 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.
[...]
quoted text
> 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).

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