Re: Rebasing stgit stacks

From: Yann Dirson <ydirson@altern.org>
Date: Jan 20, 2007, 13:17 UTC
Message-ID: <20070120131716.GA4684@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <200701191040.17476.jnareb@gmail.com>

On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:

Show 5 quoted lines

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

> Second, if you were to implement separating commands into subcommands
> (perhaps just as alternative names) depending on what they act on:
> "stg stack <subcommand>", "stg patch <subcommand>" etc., this would
> I think belong to "stg base <subcommand>".

Hm, the operation is not just about moving the stack base, it also has to reapply patches, so, whereas the central concept is about moving the base, the whole operation is indeed about the rebaseing the whole stack.

I'm not sure we need to expose the "stack base" to the user as an object she could manipulate all alone, I'd rather think it should only be kept a read-only attribute of the stack, which gets changed when the user rebases the stack.

IOW, the conceptual base object is private to the stack object, (it is indeed just a simple text attribute) and only stack methods are allowed to call base.move(), when they have ensured it can be done safely (ie. popping all patches first).

Best regards,

-- 
Yann.