Different behaviour of rebase -i

Different behaviour of rebase -i

[Leonardo Sobral Cunha]

hi,

While doing a git rebase with my upstream branch ahead of my local
branch, first git rewinds my local branch to point to the upstream and
then prints "Nothing to do". As expected, my local branch ends
pointing to the upstream head.

But when I use the same command with the same branches using git
rebase -i, nothing happens  and my local branch does not point to
upstream (the behaviour is different).

Is this different behaviour of rebase -i expected or is this a bug?
This is still happening in git version 1.6.0.2.443.g52e83

br,
-- 
// leo

Re: Different behaviour of rebase -i

[Caio Marcelo de Oliveira Filho]

"Leonardo Sobral Cunha" <sobral@gmail.com> writes:
> Is this different behaviour of rebase -i expected or is this a bug?
> This is still happening in git version 1.6.0.2.443.g52e83

To illustrate the problem:

----8<----
~$ git --version
git version 1.6.0.2.514.g23abd3
~$ mkdir a
~$ cd a
~/a$ git init
Initialized empty Git repository in /home/cmarcelo/a/.git/

~/a$ touch A && git add A && git commit A -m "First commit"
Created initial commit d956e0c: First commit
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 A

~/a$ touch B && git add B && git commit B -m "Second commit"
Created commit 7b6512d: Second commit
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 B

~/a$ cd ..
~$ git clone a b
Initialized empty Git repository in /home/cmarcelo/b/.git/

~$ cd b
~/b$ git reset --hard HEAD~1
HEAD is now at d956e0c First commit

~/b$ git rebase -i origin/master
Nothing to do

~/b$ git show
commit d956e0ca33e10bac8a0a14200b1e13d84535d728
Author: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Date:   Thu Oct 9 20:18:53 2008 -0300

    First commit

diff --git a/A b/A
new file mode 100644
index 0000000..e69de29

~/b$ git rebase origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to origin/master.
~/b$ git show
commit 7b6512d5f4b2c51753f4d06033651cee8e6d1460
Author: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
Date:   Thu Oct 9 20:19:11 2008 -0300

    Second commit

diff --git a/B b/B
new file mode 100644
index 0000000..e69de29
---->8----

Wasn't the first "rebase -i" supposed to get to "Second commit"?


-- 
Caio Marcelo de Oliveira Filho
OpenBossa Labs - INdT

Re: Different behaviour of rebase -i

[Johannes Schindelin]

Hi,

On Thu, 9 Oct 2008, Leonardo Sobral Cunha wrote:

> While doing a git rebase with my upstream branch ahead of my local 
> branch, first git rewinds my local branch to point to the upstream and 
> then prints "Nothing to do". As expected, my local branch ends pointing 
> to the upstream head.
> 
> But when I use the same command with the same branches using git rebase 
> -i, nothing happens and my local branch does not point to upstream (the 
> behaviour is different).
> 
> Is this different behaviour of rebase -i expected or is this a bug? This 
> is still happening in git version 1.6.0.2.443.g52e83

This is by design.  You need to have a way to stop rebasing in the editor.  
For example when you realize that you passed the wrong upstream or 
something.

The most intuitive way (I thought) is to behave the same as "git commit": 
if you do not want to continue, just delete everything.

Now, I can see that it is unconvenient.

A workaround would be to add a line "bla" and when rebase complains about 
the unknown command, continue with "git rebase --skip".

Maybe we should add a new command "noop" which is automatically inserted 
when there is no other command?

Ciao,
Dscho

[PATCH] rebase -i: do not fail when there is no commit to cherry-pick

[Johannes Schindelin]

In case there is no commit to apply (for example because you rebase to
upstream and all your local patches have been applied there), do not
fail.  The non-interactive rebase already behaves that way.

Do this by introducing a new command, "noop", which is substituted for
an empty commit list, so that deleting the commit list can still abort
as before.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Fri, 10 Oct 2008, Johannes Schindelin wrote:

	> Maybe we should add a new command "noop" which is automatically 
	> inserted when there is no other command?

	And this implements that.

 git-rebase--interactive.sh    |    3 ++-
 t/t3404-rebase-interactive.sh |   11 +++++++++++
 2 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 076414a..49a6b5c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -271,7 +271,7 @@ do_next () {
 		"$DOTEST"/amend || exit
 	read command sha1 rest < "$TODO"
 	case "$command" in
-	'#'*|'')
+	'#'*|''|noop)
 		mark_action_done
 		;;
 	pick|p)
@@ -583,6 +583,7 @@ first and then run 'git rebase --continue' again."
 			--abbrev=7 --reverse --left-right --cherry-pick \
 			$UPSTREAM...$HEAD | \
 			sed -n "s/^>/pick /p" > "$TODO"
+		test -s "$TODO" || echo noop >> "$TODO"
 		cat >> "$TODO" << EOF
 
 # Rebase $SHORTUPSTREAM..$SHORTHEAD onto $SHORTONTO
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index e0ded19..7d10a27 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -419,4 +419,15 @@ test_expect_success 'rebase with a file named HEAD in worktree' '
 
 '
 
+test_expect_success 'do "noop" when there is nothing to cherry-pick' '
+
+	git checkout -b branch4 HEAD &&
+	GIT_EDITOR=: git commit --amend \
+		--author="Somebody else <somebody@else.com>" 
+	test $(git rev-parse branch3) != $(git rev-parse branch4) &&
+	git rebase -i branch3 &&
+	test $(git rev-parse branch3) = $(git rev-parse branch4)
+
+'
+
 test_done
-- 
1.6.0.2.713.g3dcb0