{"thread":{"id":"20195","subject":"[PATCH v2 0/1] Fix rebase -p --onto","startedAt":"2009-07-22T16:37:38Z","lastAt":"2009-07-22T18:05:13Z","messageCount":5,"participants":["Greg Price","Johannes Schindelin"],"isPatch":true,"patchVersion":2,"patchTotal":1},"messages":[{"id":"118464","messageId":"20090722163738.GO7503@vinegar-pot.mit.edu","threadId":"20195","inReplyTo":null,"subject":"[PATCH v2 0/1] Fix rebase -p --onto","fromName":"Greg Price","fromEmail":"price@ksplice.com","sentAt":"2009-07-22T16:37:38Z","receivedAt":"2009-07-22T16:37:38Z","isPatch":true,"sender":{"key":"price@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28173?v=4"},"body":"I sent a version of the following patch last week to fix the behavior\nof rebase -p to respect --onto.  Some questions were raised and I\nbelieve I've addressed all of them.\n\nThe code already distinguishes the cases Junio described in a natural\nway, as demonstrated by a test case in the revised patch.  The use\ncase Hannes described has never worked, as Dscho explained, and in any\ncase concerns a different part of the code from this patch -- when the\ngreat day comes that rebase -i -p can reorder commits, this patch will\nwork smoothly with that.\n\nAre there further comments?  If not, I believe this is ready for merge.\n\nGreg\n"},{"id":"118465","messageId":"20090722163858.GP7503@vinegar-pot.mit.edu","threadId":"20195","inReplyTo":"20090722163738.GO7503@vinegar-pot.mit.edu","subject":"[PATCH v2 1/1] Fix rebase -p --onto","fromName":"Greg Price","fromEmail":"price@ksplice.com","sentAt":"2009-07-22T16:38:58Z","receivedAt":"2009-07-22T16:38:58Z","isPatch":true,"sender":{"key":"price@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28173?v=4"},"body":"In a rebase with --onto, the correct test for whether we can skip\nrewriting a commit is if it is already on top of $ONTO, not $UPSTREAM.\nWithout --onto, this distinction does not exist and the behavior does\nnot change.\n\nIn a situation with two merged branches on a common base X:\n\n X---o---o---o---M\n  \\             /\n   x---x---x---x\n\n Y\n\nif we try to move the branches from their base on X to be based on Y,\nso as to get\n\n X\n\n Y---o'--o'--o'--M'\n  \\             /\n   x'--x'--x'--x'\n\nthen we fail.  The command `git rebase -p --onto Y X M` moves only the\nfirst-parent chain, like so:\n\n X\n  \\\n   x---x---x---x\n                \\\n Y---o'--o'--o'--M'\n\nbecause it mistakenly drops the other branch(es) x---x---x---x from\nthe TODO file.  This tests and fixes this behavior.\n\nSigned-off-by: Greg Price <price@ksplice.com>\n---\n git-rebase--interactive.sh      |    2 +-\n t/t3414-rebase-preserve-onto.sh |   80 +++++++++++++++++++++++++++++++++++++++\n 2 files changed, 81 insertions(+), 1 deletions(-)\n create mode 100755 t/t3414-rebase-preserve-onto.sh\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex f96d887..23ded48 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -703,7 +703,7 @@ first and then run 'git rebase --continue' again.\"\n \t\t\t\t\tpreserve=t\n \t\t\t\t\tfor p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)\n \t\t\t\t\tdo\n-\t\t\t\t\t\tif test -f \"$REWRITTEN\"/$p -a \\( $p != $UPSTREAM -o $sha1 = $first_after_upstream \\)\n+\t\t\t\t\t\tif test -f \"$REWRITTEN\"/$p -a \\( $p != $ONTO -o $sha1 = $first_after_upstream \\)\n \t\t\t\t\t\tthen\n \t\t\t\t\t\t\tpreserve=f\n \t\t\t\t\t\tfi\ndiff --git a/t/t3414-rebase-preserve-onto.sh b/t/t3414-rebase-preserve-onto.sh\nnew file mode 100755\nindex 0000000..80019ee\n--- /dev/null\n+++ b/t/t3414-rebase-preserve-onto.sh\n@@ -0,0 +1,80 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2009 Greg Price\n+#\n+\n+test_description='git rebase -p should respect --onto\n+\n+In a rebase with --onto, we should rewrite all the commits that\n+aren'\"'\"'t on top of $ONTO, even if they are on top of $UPSTREAM.\n+'\n+. ./test-lib.sh\n+\n+. ../lib-rebase.sh\n+\n+# Set up branches like this:\n+# A1---B1---E1---F1---G1\n+#  \\    \\             /\n+#   \\    \\--C1---D1--/\n+#    H1\n+\n+test_expect_success 'setup' '\n+\ttest_commit A1 &&\n+\ttest_commit B1 &&\n+\ttest_commit C1 &&\n+\ttest_commit D1 &&\n+\tgit reset --hard B1 &&\n+\ttest_commit E1 &&\n+\ttest_commit F1 &&\n+\ttest_merge G1 D1 &&\n+\tgit reset --hard A1 &&\n+\ttest_commit H1\n+'\n+\n+# Now rebase merge G1 from both branches' base B1, both should move:\n+# A1---B1---E1---F1---G1\n+#  \\    \\             /\n+#   \\    \\--C1---D1--/\n+#    \\\n+#     H1---E2---F2---G2\n+#      \\             /\n+#       \\--C2---D2--/\n+\n+test_expect_success 'rebase from B1 onto H1' '\n+\tgit checkout G1 &&\n+\tgit rebase -p --onto H1 B1 &&\n+\ttest \"$(git rev-parse HEAD^1^1^1)\" = \"$(git rev-parse H1)\" &&\n+\ttest \"$(git rev-parse HEAD^2^1^1)\" = \"$(git rev-parse H1)\"\n+'\n+\n+# On the other hand if rebase from E1 which is within one branch,\n+# then the other branch stays:\n+# A1---B1---E1---F1---G1\n+#  \\    \\             /\n+#   \\    \\--C1---D1--/\n+#    \\             \\\n+#     H1-----F3-----G3\n+\n+test_expect_success 'rebase from E1 onto H1' '\n+\tgit checkout G1 &&\n+\tgit rebase -p --onto H1 E1 &&\n+\ttest \"$(git rev-parse HEAD^1^1)\" = \"$(git rev-parse H1)\" &&\n+\ttest \"$(git rev-parse HEAD^2)\" = \"$(git rev-parse D1)\"\n+'\n+\n+# And the same if we rebase from a commit in the second-parent branch.\n+# A1---B1---E1---F1----G1\n+#  \\    \\          \\   /\n+#   \\    \\--C1---D1-\\-/\n+#    \\               \\\n+#     H1------D3------G4\n+\n+test_expect_success 'rebase from C1 onto H1' '\n+\tgit checkout G1 &&\n+\tgit rev-list --first-parent --pretty=oneline C1..G1 &&\n+\tgit rebase -p --onto H1 C1 &&\n+\ttest \"$(git rev-parse HEAD^2^1)\" = \"$(git rev-parse H1)\" &&\n+\ttest \"$(git rev-parse HEAD^1)\" = \"$(git rev-parse F1)\"\n+'\n+\n+test_done\n-- \n1.6.3.1.499.ge7b8da\n"},{"id":"118466","messageId":"alpine.DEB.1.00.0907221905360.7343@intel-tinevez-2-302","threadId":"20195","inReplyTo":"20090722163738.GO7503@vinegar-pot.mit.edu","subject":"Re: [PATCH v2 0/1] Fix rebase -p --onto","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-22T17:07:17Z","receivedAt":"2009-07-22T17:07:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 22 Jul 2009, Greg Price wrote:\n\n> [...] when the great day comes that rebase -i -p can reorder commits \n> [...]\n\nIf you want to help, I would be so thankful.  In that case, it might make \nmore sense to hold off this patch and integrate it into the rebase-i-p \npatch series, rather than requiring a rebase of rebase-i-p on top of your \npatches, which will postpone said day only further.\n\nCiao,\nDscho\n"},{"id":"118468","messageId":"20090722173635.GN7878@vinegar-pot.mit.edu","threadId":"20195","inReplyTo":"alpine.DEB.1.00.0907221905360.7343@intel-tinevez-2-302","subject":"Re: [PATCH v2 0/1] Fix rebase -p --onto","fromName":"Greg Price","fromEmail":"price@ksplice.com","sentAt":"2009-07-22T17:36:36Z","receivedAt":"2009-07-22T17:36:36Z","isPatch":true,"sender":{"key":"price@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28173?v=4"},"body":"On Wed, Jul 22, 2009 at 07:07:17PM +0200, Johannes Schindelin wrote:\n> On Wed, 22 Jul 2009, Greg Price wrote:\n> > [...] when the great day comes that rebase -i -p can reorder commits \n> \n> If you want to help, I would be so thankful.  In that case, it might make \n> more sense to hold off this patch and integrate it into the rebase-i-p \n> patch series, rather than requiring a rebase of rebase-i-p on top of your \n> patches, which will postpone said day only further.\n\nWhere is your patch series and what are the big things that need doing\nbefore it can be merged?  I can't promise a great deal of time up\nfront, but I would be glad to look at it and may be able to pitch in.\n\nBecause this patch is about --onto together with -p and doesn't really\ninvolve -i, I think it still makes sense to merge.  It's only one line\nplus tests, so I don't think it will create that much of a rebase burden.\n\nCheers,\nGreg\n"},{"id":"118472","messageId":"alpine.DEB.1.00.0907222004370.7343@intel-tinevez-2-302","threadId":"20195","inReplyTo":"20090722173635.GN7878@vinegar-pot.mit.edu","subject":"Re: [PATCH v2 0/1] Fix rebase -p --onto","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-22T18:05:13Z","receivedAt":"2009-07-22T18:05:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 22 Jul 2009, Greg Price wrote:\n\n> On Wed, Jul 22, 2009 at 07:07:17PM +0200, Johannes Schindelin wrote:\n> > On Wed, 22 Jul 2009, Greg Price wrote:\n> > > [...] when the great day comes that rebase -i -p can reorder commits \n> > \n> > If you want to help, I would be so thankful.  In that case, it might make \n> > more sense to hold off this patch and integrate it into the rebase-i-p \n> > patch series, rather than requiring a rebase of rebase-i-p on top of your \n> > patches, which will postpone said day only further.\n> \n> Where is your patch series and what are the big things that need doing\n> before it can be merged?  I can't promise a great deal of time up\n> front, but I would be glad to look at it and may be able to pitch in.\n> \n> Because this patch is about --onto together with -p and doesn't really\n> involve -i, I think it still makes sense to merge.  It's only one line\n> plus tests, so I don't think it will create that much of a rebase burden.\n\nFair enough.  I was fooled by the size of the mail; the main part is the \ntest (which is good), though, so strike my objections.\n\nCiao,\nDscho\n"}]}