* Bug in git rebase -i where <upstream> is "HEAD" in 1.5.4?
@ 2008-02-07 21:47 Adam Roben
2008-02-07 23:32 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: Adam Roben @ 2008-02-07 21:47 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Bug in git rebase -i where <upstream> is "HEAD" in 1.5.4?
2008-02-07 21:47 Bug in git rebase -i where <upstream> is "HEAD" in 1.5.4? Adam Roben
@ 2008-02-07 23:32 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2008-02-07 23:32 UTC (permalink / raw)
To: Adam Roben; +Cc: git, Johannes Schindelin
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-02-07 23:33 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-07 21:47 Bug in git rebase -i where <upstream> is "HEAD" in 1.5.4? Adam Roben
2008-02-07 23:32 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).