Yann Dirson wrote:
quoted text
> 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 ?

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 ]


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)  

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.

-- 
Jakub Narebski
Poland
-
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