{"thread":{"id":"15839","subject":"Different behaviour of rebase -i","startedAt":"2008-10-09T19:04:32Z","lastAt":"2008-10-10T11:42:12Z","messageCount":4,"participants":["Leonardo Sobral Cunha","Caio Marcelo de Oliveira Filho","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"92693","messageId":"6beb92080810091204n6df4338fs3b182194a8d6454e@mail.gmail.com","threadId":"15839","inReplyTo":null,"subject":"Different behaviour of rebase -i","fromName":"Leonardo Sobral Cunha","fromEmail":"sobral@gmail.com","sentAt":"2008-10-09T19:04:32Z","receivedAt":"2008-10-09T19:04:32Z","isPatch":false,"sender":{"key":"sobral@gmail.com","avatar":null},"body":"hi,\n\nWhile doing a git rebase with my upstream branch ahead of my local\nbranch, first git rewinds my local branch to point to the upstream and\nthen prints \"Nothing to do\". As expected, my local branch ends\npointing to the upstream head.\n\nBut when I use the same command with the same branches using git\nrebase -i, nothing happens and my local branch does not point to\nupstream (the behaviour is different).\n\nIs this different behaviour of rebase -i expected or is this a bug?\nThis is still happening in git version 1.6.0.2.443.g52e83\n\nbr,\n-- \n// leo\n"},{"id":"92723","messageId":"m3vdw1e4h4.fsf@openbossa.org","threadId":"15839","inReplyTo":"6beb92080810091204n6df4338fs3b182194a8d6454e@mail.gmail.com","subject":"Re: Different behaviour of rebase -i","fromName":"Caio Marcelo de Oliveira Filho","fromEmail":"caio.oliveira@openbossa.org","sentAt":"2008-10-09T23:25:11Z","receivedAt":"2008-10-09T23:25:11Z","isPatch":false,"sender":{"key":"caio.oliveira@openbossa.org","avatar":null},"body":"\n\"Leonardo Sobral Cunha\" writes:\n> Is this different behaviour of rebase -i expected or is this a bug?\n> This is still happening in git version 1.6.0.2.443.g52e83\n\nTo illustrate the problem:\n\n----8<----\n~$ git --version\ngit version 1.6.0.2.514.g23abd3\n~$ mkdir a\n~$ cd a\n~/a$ git init\nInitialized empty Git repository in /home/cmarcelo/a/.git/\n\n~/a$ touch A && git add A && git commit A -m \"First commit\"\nCreated initial commit d956e0c: First commit\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 A\n\n~/a$ touch B && git add B && git commit B -m \"Second commit\"\nCreated commit 7b6512d: Second commit\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 B\n\n~/a$ cd ..\n~$ git clone a b\nInitialized empty Git repository in /home/cmarcelo/b/.git/\n\n~$ cd b\n~/b$ git reset --hard HEAD~1\nHEAD is now at d956e0c First commit\n\n~/b$ git rebase -i origin/master\nNothing to do\n\n~/b$ git show\ncommit d956e0ca33e10bac8a0a14200b1e13d84535d728\nAuthor: Caio Marcelo de Oliveira Filho \nDate: Thu Oct 9 20:18:53 2008 -0300\n\n First commit\n\ndiff --git a/A b/A\nnew file mode 100644\nindex 0000000..e69de29\n\n~/b$ git rebase origin/master\nFirst, rewinding head to replay your work on top of it...\nFast-forwarded master to origin/master.\n~/b$ git show\ncommit 7b6512d5f4b2c51753f4d06033651cee8e6d1460\nAuthor: Caio Marcelo de Oliveira Filho \nDate: Thu Oct 9 20:19:11 2008 -0300\n\n Second commit\n\ndiff --git a/B b/B\nnew file mode 100644\nindex 0000000..e69de29\n---->8----\n\nWasn't the first \"rebase -i\" supposed to get to \"Second commit\"?\n\n\n-- \nCaio Marcelo de Oliveira Filho\nOpenBossa Labs - INdT\n"},{"id":"92746","messageId":"alpine.DEB.1.00.0810101319150.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15839","inReplyTo":"6beb92080810091204n6df4338fs3b182194a8d6454e@mail.gmail.com","subject":"Re: Different behaviour of rebase -i","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-10T11:40:47Z","receivedAt":"2008-10-10T11:40:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 9 Oct 2008, Leonardo Sobral Cunha wrote:\n\n> While doing a git rebase with my upstream branch ahead of my local \n> branch, first git rewinds my local branch to point to the upstream and \n> then prints \"Nothing to do\". As expected, my local branch ends pointing \n> to the upstream head.\n> \n> But when I use the same command with the same branches using git rebase \n> -i, nothing happens and my local branch does not point to upstream (the \n> behaviour is different).\n> \n> Is this different behaviour of rebase -i expected or is this a bug? This \n> is still happening in git version 1.6.0.2.443.g52e83\n\nThis is by design. You need to have a way to stop rebasing in the editor. \nFor example when you realize that you passed the wrong upstream or \nsomething.\n\nThe most intuitive way (I thought) is to behave the same as \"git commit\": \nif you do not want to continue, just delete everything.\n\nNow, I can see that it is unconvenient.\n\nA workaround would be to add a line \"bla\" and when rebase complains about \nthe unknown command, continue with \"git rebase --skip\".\n\nMaybe we should add a new command \"noop\" which is automatically inserted \nwhen there is no other command?\n\nCiao,\nDscho\n"},{"id":"92747","messageId":"alpine.DEB.1.00.0810101341120.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15839","inReplyTo":"alpine.DEB.1.00.0810101319150.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"[PATCH] rebase -i: do not fail when there is no commit to cherry-pick","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-10T11:42:12Z","receivedAt":"2008-10-10T11:42:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nIn case there is no commit to apply (for example because you rebase to\nupstream and all your local patches have been applied there), do not\nfail. The non-interactive rebase already behaves that way.\n\nDo this by introducing a new command, \"noop\", which is substituted for\nan empty commit list, so that deleting the commit list can still abort\nas before.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Fri, 10 Oct 2008, Johannes Schindelin wrote:\n\n\t> Maybe we should add a new command \"noop\" which is automatically \n\t> inserted when there is no other command?\n\n\tAnd this implements that.\n\n git-rebase--interactive.sh | 3 ++-\n t/t3404-rebase-interactive.sh | 11 +++++++++++\n 2 files changed, 13 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 076414a..49a6b5c 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -271,7 +271,7 @@ do_next () {\n \t\t\"$DOTEST\"/amend || exit\n \tread command sha1 rest < \"$TODO\"\n \tcase \"$command\" in\n-\t'#'*|'')\n+\t'#'*|''|noop)\n \t\tmark_action_done\n \t\t;;\n \tpick|p)\n@@ -583,6 +583,7 @@ first and then run 'git rebase --continue' again.\"\n \t\t\t--abbrev=7 --reverse --left-right --cherry-pick \\\n \t\t\t$UPSTREAM...$HEAD | \\\n \t\t\tsed -n \"s/^>/pick /p\" > \"$TODO\"\n+\t\ttest -s \"$TODO\" || echo noop >> \"$TODO\"\n \t\tcat >> \"$TODO\" << EOF\n \n # Rebase $SHORTUPSTREAM..$SHORTHEAD onto $SHORTONTO\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex e0ded19..7d10a27 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -419,4 +419,15 @@ test_expect_success 'rebase with a file named HEAD in worktree' '\n \n '\n \n+test_expect_success 'do \"noop\" when there is nothing to cherry-pick' '\n+\n+\tgit checkout -b branch4 HEAD &&\n+\tGIT_EDITOR=: git commit --amend \\\n+\t\t--author=\"Somebody else \" \n+\ttest $(git rev-parse branch3) != $(git rev-parse branch4) &&\n+\tgit rebase -i branch3 &&\n+\ttest $(git rev-parse branch3) = $(git rev-parse branch4)\n+\n+'\n+\n test_done\n-- \n1.6.0.2.713.g3dcb0\n"}]}