Re: [RFC][StGit PATCH] Add support for merge-friendly branches

[Catalin Marinas <catalin.marinas@gmail.com>]

2009/5/29 Karl Hasselström <kha@treskal.com>:
> On 2009-05-28 15:38:44 +0100, Catalin Marinas wrote:
> I think I would've kludged this by making --theirs merges from the
> StGit branch to the public branch. But "stg publish" should definitely
> make the kludge history less ugly.

That's what I'm trying to do, keep the public history clean. One
advantage of merging the full StGit branch is that people could
retrieve the latest patch version but for those interesting in
cherry-picking you can just export the volatile StGit branch.

Regarding the resulting tree, rebasing a StGit stack is equivalent, on
a linear history branch, to a merge of the new stack base into the
linear branch. Rather than having to solve conflicts twice, the pubish
command just fakes this merge and sets the resulting tree.

>> > Hmm. Couldn't the merge base conceivably be higher up in the
>> > stack? Like, right at the beginning, don't we have public_head ==
>> > stack.head? That would be caught by the "same tree" check" a bit
>> > earlier, but after adding another patch, don't we have public_head
>> > == stack.head^ ? Which would give merge_base == public_head.
>>
>> We could have public_head == stack.head^... but that's not an issue.
>> The merge_base above is checked against the base of the stack rather
>> than the top as we assume that the base isn't volatile. So even if
>> public_head is the same as some patch commit, the merge_base above
>> would always be the base of the stack. Only if the stack base was
>> updated, we get a different merge_base (equal to the previous stack
>> base).
>
> The situation I described looks like this:
>
>    B--o--o--o--o--o--P--T
>
> Time goes from left to right. B is the stack base, P the head of the
> public branch, T the stack top. merge_base(P, T) is P, and not B.

I don't check merge_base(P, T) but merge_base(P, B) to avoid the
issues you described. So that's always B.

-- 
Catalin