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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2009-05-28 15:38:44 +0100, Catalin Marinas wrote:

> 2009/5/28 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > On 2009-05-28 12:12:42 +0100, Catalin Marinas wrote:
> >
> > > 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.

> > 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@xxxxxxxxxxx
      www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]