Re: Rebasing stgit stacks

["Catalin Marinas" <catalin.marinas@gmail.com>]

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

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

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

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

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