git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
CMCatalin Marinas <catalin.marinas@gmail.com>
Date
May 29, 2009, 09:16 UTC
Message-ID
<b0943d9e0905290216m3c2bb639kc951510c72212ff@mail.gmail.com>
In-Reply-To
<20090529083739.GB9760@diana.vm.bytemark.co.uk>
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.

Show 20 quoted lines
>> > 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
Previous: Karl HasselströmNext: Karl Hasselström
Message 10 of 12 in “Add support for merge-friendly branches”
  1. Catalin MarinasMay 28, 2009
  2. Karl HasselströmMay 28, 2009
  3. Catalin MarinasMay 28, 2009
  4. Catalin MarinasMay 28, 2009
  5. Karl HasselströmMay 29, 2009
  6. Catalin MarinasMay 29, 2009
  7. Karl HasselströmMay 29, 2009
  8. Catalin MarinasMay 29, 2009
  9. Karl HasselströmMay 29, 2009
  10. Catalin MarinasMay 29, 2009
  11. Karl HasselströmMay 29, 2009
  12. Fwd: [RFC][StGit PATCH] Add support for merge-friendly branchesmartin f krafft, May 28, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.