Re: Rebasing stgit stacks

From: Yann Dirson <ydirson@altern.org>
Date: Jan 20, 2007, 20:07 UTC
Message-ID: <20070120200706.GC4684@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <200701202016.16333.jnareb@gmail.com>

On Sat, Jan 20, 2007 at 08:16:15PM +0100, Jakub Narebski wrote:

Show 34 quoted lines

> Yann Dirson wrote:
> > On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:
> 
> >> First, "stg rebase" when on some git branch might mean rebase StGIT
> >> stack to head of current branch (because there were some git commits
> >> on top of this branch). So it would be "stg rebase [--onto <target>]";
> >> it would be command without non-option arg, but this arg would be
> >> optional.
> > 
> > I'm not sure I understand.  Since the "current StGIT stack" is the one
> > pointed to by HEAD, how do you specify, when HEAD points to the target
> > branch, which stack to rebase ?
> 
> Well, I haven't thought this through. I was thinking about situation
> where there are no applied patches, and some commits were done without
> StGIT (pure git), i.e. we had
> 
>                   ..1...2...3  <-- unapplied (deck) [ branch ]
>                  /
>     a---b---c---d   <-- HEAD [ branch ]
> 
> There were some git commits (for example fetch, or cherry-pick, or ...)
> 
> 
>                   ..1...2...3  <-- unapplied (deck) [ branch ]
>                  /
>     a---b---c---d---e---f   <-- HEAD [ branch ]
> 
> And after "stg rebase" I want to have:
> 
> 
>                           ..1...2...3  <-- unapplied (deck) [ branch ]
>                          /
>     a---b---c---d---e---f   <-- HEAD [ branch ]

So this what we typically currently get by using "stg pull . branchname", when HEAD is the stack branch.

I can easily see that called as "stg rebase", with --to argument defaulting to parent branch (as given by branch.<name>.merge) when the HEAD is the stack branch. That would be a neat replacement for "stg pull . <name>".

Calling 'stg rebase' from the branch to rebase onto, however, can't guess which stack to rebase - there are possibly many stacks forked off your branch. In that case, you will need to ask "stg rebase <mystack>".

But this will mean that "stg rebase <mystack>" will have --to default to HEAD, whereas "stg rebase" will have --to default to the stack's parent branch. Not sure, but that looks a bit inconsistent, and may be confusing. But probably we can implement things this way, and wait for the user feedback to see if some restructuration is called, post-1.0, when we move to subcommands.

Show 9 quoted lines

> I'm not sure how should the above work with applied patches
> (non-empty stack), i.e. with the following:
> 
>                           ..3...4...5  <-- unapplied (deck) [ branch ]
>                          /
>     a---b---c---d-.-1-.-2   <-- HEAD [ branch ]
>                   \--v--/
> 
>                   (stack)

As long as commits occured as children of 'd', 'rebase' will take care of applied patches (it pops all patches first).

> Or for example git branch got rebased, and I want to move also deck
> (unapplied patches), because "git rebase" don't move them... unless
> this is not needed. Probably it is not needed.

This is a typical ouse for "stg rebase", it should just work.

Best regards,

-- 
Yann.