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

From: Catalin Marinas <catalin.marinas@arm.com>
Date: Nov 19, 2007, 17:47 UTC
Message-ID: <tnxbq9qyvom.fsf@pc1117.cambridge.arm.com>
In-Reply-To: <9e4733910711181042x123e99efjad38486654db17e2@mail.gmail.com>

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

[...]

Show 11 quoted lines

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

[...]

Show 7 quoted lines

> 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