On Wed, Jan 17, 2007 Yann Dirson wrote: > On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote: >> I'm all for calling this command "stg rebase". > > After all, my current implementation as "pull --to" mostly bypasses > the fetch, so it probably makes sense to use a new command. > > However, "stg rebase <target>" does not sound right. I'm not very > happy with "stg rebaseto <target>" (or rebase-to) either. > "stg rebase --to <target>" may feel strange too (command without > non-option arg), but may finally a good choice after all ? What do > others think ? 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. 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>". -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html