# Bug in git rebase -i where <upstream> is "HEAD" in 1.5.4?

2 messages from 2008-02-07 to 2008-02-07. Participants: Adam Roben, Junio C Hamano.
Thread: https://gitlist.dev/t/11955

## Adam Roben, 2008-02-07 21:47

Subject: Bug in git rebase -i where <upstream> is "HEAD" in 1.5.4?
Message-ID: <D94A5309-3EB0-46FA-9114-D11376585DBB@apple.com>
URL: https://gitlist.dev/e/D94A5309-3EB0-46FA-9114-D11376585DBB%40apple.com

```
Hi all-
    I've discovered a difference in behavior between `git rebase` and  
`git rebase -i`, and I believe the behavior exhibited by `git rebase - 
i` is incorrect and should be changed to match `git rebase`. The  
behavior difference occurs when running the command in the form:

git rebase [-i] <upstream> <branch>

    If <upstream> is "HEAD", `git rebase` seems to perform these  
(correct) steps:

A=$(git rev-parse HEAD)
git checkout <branch>
git rebase $A

    However, `git rebase -i` seems to perform these (incorrect) steps:

git checkout <branch>
git rebase -i HEAD

    The problem is that `git checkout` changes the meaning of HEAD  
(naturally), and so these steps are not equivalent. The end result is  
that `git rebase -i HEAD <branch>` just checks out <branch> and prints  
"Nothing to do", while when -i is omitted the rebase occurs as  
expected. Below is a transcript that shows exactly what I mean.

-Adam


% git init
Initialized empty Git repository in .git/
% touch onmaster
% git add onmaster
% git commit -m "Added onmaster"
Created initial commit 7c3e0f1: Added onmaster
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 onmaster
% touch onmaster2
% git add onmaster2
% git commit -m "Added onmaster2"
Created commit c19019b: Added onmaster2
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 onmaster2
% git checkout -b work HEAD^
Switched to a new branch "work"
% touch onwork
% git add onwork
% git commit -m "Added onwork"
Created commit ae14495: Added onwork
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 onwork
% touch onwork2
% git add onwork2
% git commit -m "Added onwork2"
Created commit 64b3dc0: Added onwork2
  0 files changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 onwork2
% ls
onmaster onwork   onwork2
% git checkout master
Switched to branch "master"
% ls
onmaster  onmaster2
% git rebase -i HEAD work
Nothing to do
% ls
onmaster onwork   onwork2

```

## Junio C Hamano, 2008-02-07 23:32

Subject: Re: Bug in git rebase -i where <upstream> is "HEAD" in 1.5.4?
Message-ID: <7vlk5wmjfn.fsf@gitster.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vlk5wmjfn.fsf%40gitster.siamese.dyndns.org
In-Reply-To: <D94A5309-3EB0-46FA-9114-D11376585DBB@apple.com>

```
Adam Roben <aroben@apple.com> writes:

>    I've discovered a difference in behavior between `git rebase` and
> `git rebase -i`, and I believe the behavior exhibited by `git rebase -
> i` is incorrect and should be changed to match `git rebase`. The
> behavior difference occurs when running the command in the form:
>
> git rebase [-i] <upstream> <branch>
>
>    If <upstream> is "HEAD", `git rebase` seems to perform these
> (correct) steps:
>
> A=$(git rev-parse HEAD)
> git checkout <branch>
> git rebase $A

Yes, I remember writing that side carefully, taking exactly this
issue into account.

>    However, `git rebase -i` seems to perform these (incorrect) steps:

Yeah, I see that interactive side is sloppier.  In
git-rebase--interactive.sh, if you move

        HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
        UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"

around l.481 up so that they come before if test !  -z "$2",
you would be Ok, although I didn't test it.

```