On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:
quoted text
> 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 ?

quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html