From: Junio C Hamano <gitster@pobox.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 1/3] t/checkout-last: checkout - doesn't work after rebase -i
Date: Mon, 10 Jun 2013 11:29:03 -0700 [thread overview]
Message-ID: <7vhah5izv4.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1370881332-9231-2-git-send-email-artagnon@gmail.com> (Ramkumar Ramachandra's message of "Mon, 10 Jun 2013 21:52:10 +0530")
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> The following command
>
> $ git checkout -
>
> does not work as expected after a 'git rebase -i'.
>
> Add a failing test documenting this bug.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> t/t2012-checkout-last.sh | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
> index b44de9d..5729487 100755
> --- a/t/t2012-checkout-last.sh
> +++ b/t/t2012-checkout-last.sh
> @@ -116,4 +116,12 @@ test_expect_success 'master...' '
> test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
> '
>
> +test_expect_failure '"checkout -" works after an interactive rebase' '
> + git checkout master &&
> + git checkout other &&
> + git rebase -i master &&
> + git checkout - &&
> + test "z$(git symbolic-ref HEAD)" = "zrefs/heads/master"
> +'
Hmph, you were on "other" and then ran "rebase -i" to rebase it.
When you are done, you are on "other". You want to go back to the
one before you checked out the branch you started your "rebase -i"
on, which is "master".
OK, the expectation makes sense to me.
These four are all valid ways to spell the "rebase -i master" step.
git rebase -i master
git rebase -i --onto master master
git rebase -i master other
git rebase -i --onto master master other
and I think it is sensible to expect
(1) they all behave the same way; or
(2) the first two behave the same, but the latter two explicitly
checks out 'other' by giving the last argument. If you are not
on 'other' when you run the "rebase -i", "checkout -" should
come back to the branch before 'other', i.e. the branch you
started your "rebase -i" on.
In other words, (2) would mean:
git checkout master &&
git checkout -b naster &&
git rebase -i master other &&
# ends up on other
test_string_equal "$(git symbolic-ref HEAD)" refs/heads/other &&
git checkout - &&
# we were on naster before we rebased 'other'
test_string_equal "$(git symbolic-ref HEAD)" refs/heads/naster
It is a bit unclear what the following should expect.
git checkout master &&
git checkout other &&
git rebase -i master other &&
# ends up on other
test_string_equal "$(git symbolic-ref HEAD)" refs/heads/other &&
git checkout - &&
# we are on ??? before we rebased other
test_string_equal "$(git symbolic-ref HEAD)" refs/heads/???
One could argue that the "first checkout other and then rebase" done
by rebase becomes a no-op and the user should be aware of that
because rebase is started while on that other branch, in which case
we should come back to 'master'. From consistency point of view,
one could instead argue that we were on 'other' before we rebased
it, in which case it may not be unreasonable for "checkout -" to
come back to 'other'. I tend to prefer the former (i.e. go back to
'master') over the latter but not by a large margin.
next prev parent reply other threads:[~2013-06-10 18:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-10 16:22 [PATCH 0/3] Fix git checkout - (early preview) Ramkumar Ramachandra
2013-06-10 16:22 ` [PATCH 1/3] t/checkout-last: checkout - doesn't work after rebase -i Ramkumar Ramachandra
2013-06-10 18:29 ` Junio C Hamano [this message]
2013-06-13 7:13 ` Ramkumar Ramachandra
2013-06-10 16:22 ` [PATCH 2/3] checkout: respect GIT_REFLOG_ACTION Ramkumar Ramachandra
2013-06-10 18:31 ` Junio C Hamano
2013-06-10 16:22 ` [PATCH 3/3] rebase -i: write better reflog messages for start Ramkumar Ramachandra
2013-06-10 18:32 ` Junio C Hamano
2013-06-10 18:36 ` Ramkumar Ramachandra
2013-06-13 10:32 ` Ramkumar Ramachandra
2013-06-13 16:55 ` Junio C Hamano
2013-06-13 17:05 ` Ramkumar Ramachandra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vhah5izv4.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).