On Sat, Jan 20, 2007 at 08:16:15PM +0100, Jakub Narebski wrote: > 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. > 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. - 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