{"thread":{"id":"7969","subject":"[StGIT PATCH] Test \"stg rebase\" after \"stg commit\"","startedAt":"2007-05-04T08:13:21Z","lastAt":"2007-06-02T19:04:29Z","messageCount":6,"participants":["Karl Hasselström","Yann Dirson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"41017","messageId":"20070504081021.14786.77675.stgit@yoghurt","threadId":"7969","inReplyTo":null,"subject":"[StGIT PATCH] Test \"stg rebase\" after \"stg commit\"","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-04T08:13:21Z","receivedAt":"2007-05-04T08:13:21Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"Two new tests for \"stg rebase\":\n\n  1. Try to rebase to a commit that is ahead of HEAD. This should\n     work, and does.\n\n  2. Try to commit a patch, and then rebase. This doesn't work,\n     because \"stg rebase\" aborts if orig-base != base, and \"stg\n     commit\" doesn't update orig-base. (It does work if \"stg rebase\"\n     is given the --force flag.)\n\nSigned-off-by: Karl Hasselström <kha@treskal.com>\n---\n\n(2) shows a bug in \"stg rebase\"'s safety logic. I'm not sure how to\nfix it, because I don't know how it's supposed to work in the first\nplace. (An obvious fix would be to update it whenever the base\nchanges, but that'll take some work, and I'm not convinced it can't be\ndone with les work. Yes, I'm lazy.) Yann, could you explain?\n\n t/t2200-rebase.sh |   16 ++++++++++++++++\n 1 files changed, 16 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t2200-rebase.sh b/t/t2200-rebase.sh\nindex 52462dd..b48e513 100755\n--- a/t/t2200-rebase.sh\n+++ b/t/t2200-rebase.sh\n@@ -30,4 +30,20 @@ test_expect_success \\\n \ttest `stg id base@stack` = `git rev-parse master~1`\n \t'\n \n+test_expect_success \\\n+\t'Rebase to next commit' \\\n+\t'\n+\tstg rebase master &&\n+\ttest $(stg id base@stack) = $(git rev-parse master)\n+\t'\n+\n+test_expect_success \\\n+\t'Commit the patch and rebase again' \\\n+\t'\n+\tstg commit &&\n+\tgit tag committed-here &&\n+\tstg rebase master &&\n+\ttest $(stg id base@stack) = $(git rev-parse master)\n+\t'\n+\n test_done\n"},{"id":"41202","messageId":"20070506122116.GA18883@diana.vm.bytemark.co.uk","threadId":"7969","inReplyTo":"20070504081021.14786.77675.stgit@yoghurt","subject":"Re: [StGIT PATCH] Test \"stg rebase\" after \"stg commit\"","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T12:21:16Z","receivedAt":"2007-05-06T12:21:16Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-04 10:13:21 +0200, Karl Hasselström wrote:\n\n>   2. Try to commit a patch, and then rebase. This doesn't work,\n>      because \"stg rebase\" aborts if orig-base != base, and \"stg\n>      commit\" doesn't update orig-base. (It does work if \"stg rebase\"\n>      is given the --force flag.)\n>\n> (2) shows a bug in \"stg rebase\"'s safety logic. I'm not sure how to\n> fix it, because I don't know how it's supposed to work in the first\n> place. (An obvious fix would be to update it whenever the base\n> changes, but that'll take some work, and I'm not convinced it can't\n> be done with les work. Yes, I'm lazy.) Yann, could you explain?\n\nAnother reason why this is impractical is that it's not only stgit\nthat's allowed to change the base. For example, doing \"stg pop -a &&\ngit reset --hard foobar && stg rebase qwrtflsptk\" will also trigger\nthe alarm.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"41208","messageId":"20070506131554.GF19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"7969","inReplyTo":"20070506122116.GA18883@diana.vm.bytemark.co.uk","subject":"Re: [StGIT PATCH] Test \"stg rebase\" after \"stg commit\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-06T13:15:54Z","receivedAt":"2007-05-06T13:15:54Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, May 06, 2007 at 02:21:16PM +0200, Karl Hasselström wrote:\n> On 2007-05-04 10:13:21 +0200, Karl Hasselström wrote:\n> \n> >   2. Try to commit a patch, and then rebase. This doesn't work,\n> >      because \"stg rebase\" aborts if orig-base != base, and \"stg\n> >      commit\" doesn't update orig-base. (It does work if \"stg rebase\"\n> >      is given the --force flag.)\n> >\n> > (2) shows a bug in \"stg rebase\"'s safety logic. I'm not sure how to\n> > fix it, because I don't know how it's supposed to work in the first\n> > place. (An obvious fix would be to update it whenever the base\n> > changes, but that'll take some work, and I'm not convinced it can't\n> > be done with les work. Yes, I'm lazy.) Yann, could you explain?\n\nThe idea of the safety logic is that by default stgit should not loose\na commit without the user knowing.  That is, if you used \"stg commit\",\nthe patch you committed is most probably only reachable through the\nhead of your stack, and rebasing may make it unreachable (unless you\nhave explicitely added a new ref to it, in which case you know what\nyou're doing and you know you can \"rebase --force\").\n\n> Another reason why this is impractical is that it's not only stgit\n> that's allowed to change the base. For example, doing \"stg pop -a &&\n> git reset --hard foobar && stg rebase qwrtflsptk\" will also trigger\n> the alarm.\n\nSure, but \"pop -a && git reset\" is exactly a \"rebase -n\".  If you use\nstgit in this case instead of the plumbing, the rebase safety will not\ntrigger.  If you use the plumbing, you're out the scope of stgit which\ncannot guess what you really want, and you should use --force because\nyou're supposed to know better.\n\nBut well, that's the general idea, and this safety mechanism is quite\nyoung, it is surely possible to make it better.  But IMHO the base\nprinciple when dealing with this is that we should make every effort\nso the user does not unkwingly loose a commit (which was the case\nwithout the safety).  OTOH, it is sure that the safety must not be\noverly zealous, or we'll just end up teaching users to --force without\nthinking.\n\nThat said, I have not looked at your testcase yet, I'll try to do this\nsoon.\n\nBest regards,\n-- \nYann.\n"},{"id":"41209","messageId":"20070506133909.GG19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"7969","inReplyTo":"20070506131554.GF19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT PATCH] Test \"stg rebase\" after \"stg commit\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-06T13:39:09Z","receivedAt":"2007-05-06T13:39:09Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, May 06, 2007 at 03:15:54PM +0200, Yann Dirson wrote:\n> That said, I have not looked at your testcase yet, I'll try to do this\n> soon.\n\nOh, timeslot allocated :)\n\nWell, this case clearly falls in the category of \"actions outside\nstgit that make it possible to rebase without a loss\".  But then it is\nalso clear that the action of tagging makes the committed patch\nreachable, and thus the rebase loss-less.\n\nThe safety check could be possibly be rewritten as \"check if current\nbase is reachable without using any refs from current series\".\n\nBest regards,\n-- \nYann.\n"},{"id":"41212","messageId":"20070506142233.GA20017@diana.vm.bytemark.co.uk","threadId":"7969","inReplyTo":"20070506133909.GG19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [StGIT PATCH] Test \"stg rebase\" after \"stg commit\"","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-06T14:22:33Z","receivedAt":"2007-05-06T14:22:33Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-06 15:39:09 +0200, Yann Dirson wrote:\n\n> Well, this case clearly falls in the category of \"actions outside\n> stgit that make it possible to rebase without a loss\". But then it\n> is also clear that the action of tagging makes the committed patch\n> reachable, and thus the rebase loss-less.\n>\n> The safety check could be possibly be rewritten as \"check if current\n> base is reachable without using any refs from current series\".\n\nYes, I like that idea _much_ better. That's what we _should_ be\ntesting for, given that the objective is to keep all commits\nreachable.\n\nSo, how can we do that? gitk displays, when you view a commit, the\nheads through which that commit is reachable. How does it compute\nthat? Hmm, it seems like this type of construct works for selecting\nonly those commits that are only reachable through a given ref:\n\n  gitk origin/pu --not $(git show-ref | grep -v refs/remotes/origin/pu| cut -f 1 -d ' ')\n\nOf course, one could use git log instead of gitk if it turns out to be\ntoo hard to write an x-windows parser for stgit. :-)\n\nHowever, I'm not sure even this is necessary; reflogs are enabled by\ndefault nowadays. But if it's cheap enough, we might as well.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"43823","messageId":"20070602190429.GA6992@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"7969","inReplyTo":"20070506142233.GA20017@diana.vm.bytemark.co.uk","subject":"Re: [StGIT PATCH] Test \"stg rebase\" after \"stg commit\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-02T19:04:29Z","receivedAt":"2007-06-02T19:04:29Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, May 06, 2007 at 04:22:33PM +0200, Karl Hasselström wrote:\n> On 2007-05-06 15:39:09 +0200, Yann Dirson wrote:\n> \n> > Well, this case clearly falls in the category of \"actions outside\n> > stgit that make it possible to rebase without a loss\". But then it\n> > is also clear that the action of tagging makes the committed patch\n> > reachable, and thus the rebase loss-less.\n> >\n> > The safety check could be possibly be rewritten as \"check if current\n> > base is reachable without using any refs from current series\".\n> \n> Yes, I like that idea _much_ better. That's what we _should_ be\n> testing for, given that the objective is to keep all commits\n> reachable.\n> \n> So, how can we do that? gitk displays, when you view a commit, the\n> heads through which that commit is reachable. How does it compute\n> that? Hmm, it seems like this type of construct works for selecting\n> only those commits that are only reachable through a given ref:\n> \n>   gitk origin/pu --not $(git show-ref | grep -v refs/remotes/origin/pu| cut -f 1 -d ' ')\n> \n> Of course, one could use git log instead of gitk if it turns out to be\n> too hard to write an x-windows parser for stgit. :-)\n\nIndeed, gitk calls git-rev-list with those arguments, so the check can\nbe easily rewritten :)\n\nBest regards,\n-- \nYann\n"}]}