Re: Rebasing stgit stacks

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jan 22, 2007, 22:58 UTC
Message-ID: <b0943d9e0701221458r77b2b48hfa41d3dffcb848d0@mail.gmail.com>
In-Reply-To: <20070122194756.GA4083@nan92-1-81-57-214-146.fbx.proxad.net>

On 22/01/07, Yann Dirson <ydirson@altern.org> wrote:

Show 9 quoted lines

> 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).

> > 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.

Show 5 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)?

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 added the commit command to have a way to freeze this state into the current branch and no longer manage them with StGIT.

Show 6 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'. 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.

Show 7 quoted lines

> > > Although usually you have separate branch as StGIT stack "base", and
> > > you can simply rebase git branch, then do
> > >
> > >   $ stg rebase
>
> Oh, I think I understand - he probably uses "base" to refer to what I
> call "parent branch", and not to the refs/bases/<branch> reference...

The ref/bases/<branch> is not used much in StGIT. I initially added it as a way to see the base of a stack in gitk but that's probably the only usecase.

-- 
Catalin