On Sun, May 06, 2007 at 02:21:16PM +0200, Karl Hasselström wrote: > On 2007-05-04 10:13:21 +0200, Karl Hasselström wrote: > > > 2. Try to commit a patch, and then rebase. This doesn't work, > > because "stg rebase" aborts if orig-base != base, and "stg > > commit" doesn't update orig-base. (It does work if "stg rebase" > > is given the --force flag.) > > > > (2) shows a bug in "stg rebase"'s safety logic. I'm not sure how to > > fix it, because I don't know how it's supposed to work in the first > > place. (An obvious fix would be to update it whenever the base > > changes, but that'll take some work, and I'm not convinced it can't > > be done with les work. Yes, I'm lazy.) Yann, could you explain? The idea of the safety logic is that by default stgit should not loose a commit without the user knowing. That is, if you used "stg commit", the patch you committed is most probably only reachable through the head of your stack, and rebasing may make it unreachable (unless you have explicitely added a new ref to it, in which case you know what you're doing and you know you can "rebase --force"). > Another reason why this is impractical is that it's not only stgit > that's allowed to change the base. For example, doing "stg pop -a && > git reset --hard foobar && stg rebase qwrtflsptk" will also trigger > the alarm. Sure, but "pop -a && git reset" is exactly a "rebase -n". If you use stgit in this case instead of the plumbing, the rebase safety will not trigger. If you use the plumbing, you're out the scope of stgit which cannot guess what you really want, and you should use --force because you're supposed to know better. But well, that's the general idea, and this safety mechanism is quite young, it is surely possible to make it better. But IMHO the base principle when dealing with this is that we should make every effort so the user does not unkwingly loose a commit (which was the case without the safety). OTOH, it is sure that the safety must not be overly zealous, or we'll just end up teaching users to --force without thinking. That said, I have not looked at your testcase yet, I'll try to do this soon. 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