Re: Rebasing stgit stacks

From: Yann Dirson <ydirson@altern.org>
Date: Jan 23, 2007, 07:49 UTC
Message-ID: <20070123074945.GB4083@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0701221458r77b2b48hfa41d3dffcb848d0@mail.gmail.com>

On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:

Show 17 quoted lines

> On 22/01/07, Yann Dirson <ydirson@altern.org> wrote:
> >On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote:
> >> Currently, in the StGIT terminology stack and branch are about the
> >> same. If you want to move to a different stack, just use the "stg
> >> branch" command.
> >
> >I think you missed the point.  StGIT stacks are usually forked off
> >another branch.  As I understand it, Jakub talks about standard
> >rebasing, ie. moving the stack base from its current parent branch to
> >a new one.
> 
> StGIT stacks are a series of volatile commits (commits) at the top of
> a branch. The idea when I started writing this tool was that a series
> of applied patches would lead to the head of the current branch. The
> branch and stack are tightly coupled and you cannot simply change the
> parent branch the stack is based on (not from a technical point but
> rather from conception one).

Well, that's now allowed by "rebase".

Show 9 quoted lines

> >> A stack is just a branch with stgit-specific metadata.
> >
> >I would rather say that an StGIT stacks uses a branch, but the stack
> >is not the branch - eg, unapplied patches do not belong to the branch.
> 
> The unapplied patches can have any commit as a parent, either in the
> direct history of the current branch or in any other branch, there is
> no restriction here. They get in line with the current branch's head
> during the push operation.

Right. I'm just emphasizing that, since they are (even temporarily) not part of the GIT branch from a GIT point of view, but part of the stack, the 2 concepts, while closely linked, are not strict subsets of each other. Rather, they share some common points, but neither would be parent of the other in a class hierarchy.

Show 8 quoted lines

> >Indeed I was thinking about that today, and thought that maybe it
> >would make sense not to use a head ref (and thus not using a real
> >branch), which would minimize the risk of someone committing by error
> >(and thus minimize the need to use "assimilate"), since porcelainish
> >commit tools would then refuse to commit there.
> 
> But isn't this what Quilt already does (i.e. a different mechanism for
> patches, on top of any SCM)?

I'm not sure wat you mean here. I'm only talking of StGIT and the GIT world here.

> One of the base ideas of StGIT is that the top patch represents the
> head of the current branch and that the patches applied on the stack
> always form the recent history of the current branch.

I'm not willing to change the concept. I'm just wondering whether using a non-head reference (eg. stacks/<name> or stacks/<name>/top) would not be better. For this we may need to consider using detached HEAD support from 1.5.0, but I'm just thinking loudly, I have not looked at what that thing provides exactly yet.

> I added the commit command to have a way to freeze this state into
> the current branch and no longer manage them with StGIT.

Show 9 quoted lines

> >> What you'd probably want is a way to import patches from a different
> >> branch/stack onto the newly checked out branch.
> >
> >Sometimes you just want to throw out an obsolete branch and move your
> >stack to a new baseline.  That said, being able to duplicate a stack
> >(and possibly rebasing it afterwards) would be useful as well.
> 
> You have 'branch --clone' (or --rename if you just want a different
> name) and now 'rebase'.

D'oh.  I was probably expecting "stack --clone" or something :)

> As I said, the idea of moving the stack (patches) on top of a
> different branch should be done as an import (or multiple
> cherry-pick or clone), otherwise we loose the coupling between
> branches and stacks.

I'll have to think more about that - I'm not sure I get you point. By moving/cloning we keep (or could keep) the patches' history. By importing we cannot do that.

Best regards,

-- 
Yann.