Thread (11 messages) flat view 11 messages, 3 authors, 2016-06-15

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

From: Karl Hasselström <hidden>
Date: 2016-06-15 22:46:52

On 2009-05-28 15:38:44 +0100, Catalin Marinas wrote:
2009/5/28 Karl Hasselström [off-list ref]:
quoted
On 2009-05-28 12:12:42 +0100, Catalin Marinas wrote:
quoted
The patch proposes a new StGit command called "publish". This
command allows one to develop patches normally on a StGit branch
but publish the stack changes to a separate, merge-friendly
branch whose history is not re-writable.
Hmm, interesting. I don't think I'd want to use a command like
this myself, but I can see how it might be useful.
For me it is useful. I publish a kernel tree with over 100 patches.
Later I find that one patch is buggy. The current merge-friendly
solution is to add another patch but I may want to just update the
buggy patch as it's easier when time comes to submit upstream. This,
however, rewrites the history. So with the "publish" command I just
generate another commit on top of the public branch and I always end
up with the same tree as on my stack.
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.
quoted
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.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help