git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Pierre-Luc Loyer <Pierre-Luc.Loyer@bhvr.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Git Rebase Issue
Date: Tue, 22 Dec 2015 22:02:16 +0100	[thread overview]
Message-ID: <CAP8UFD3F6+VRyEF6XuxUcC_qiY7k4a-g8J-NKBZWDk=1=m1=WA@mail.gmail.com> (raw)
In-Reply-To: <39E7EE9D306F544FAD3A0D16B7B7CAAD2C1E819D@mtlsvrmxwv02.A2M.com>

Hi,

On Tue, Dec 22, 2015 at 6:53 PM, Pierre-Luc Loyer
<Pierre-Luc.Loyer@bhvr.com> wrote:
> Hi,
>
> I've encountered a situation using rebase for which I don't understand the results, even after reading the documentation.
> I'm currently working in my feature branch and then I want to squash commits, thus I use interactive rebase. After successfully completing the rebase, I end up in a detached HEAD state, rather than back on my branch, which is confusing. The command that is causing me to be in detached HEAD mode is: git rebase -i HEAD~2 HEAD
> From the documentation, I read that my second parameter (HEAD) is the <branch> parameter:
>
>    git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
>
>    [<upstream>] [<branch>]
>
>    If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise it remains on the current branch.
> <branch> Working branch; defaults to HEAD.
>
>    Upon completion, <branch> will be the current branch.
>
> Here is a full example than can be used to easily repro the issue. Go to an empty folder.
> git init
> git echo text > file.txt
> git add .
> git commit -m "Add file.txt"
> git echo text2 > file.txt
> git commit -am "Modify file.txt"
> git echo text3 > file.txt
> git commit -am "Remodify file.txt"
>
> Now the interesting part:
> $ git rebase -i HEAD~2 HEAD
> [detached HEAD 9178b93] Modify file
> 1 file changed, 1 insertion(+), 1 deletion(-)
> Successfully rebased and updated detached HEAD.
>
> From the documentation it says that <branch> (which is HEAD) will be checked out before doing anything and that upon completion, <branch> will be the current branch. However, this doesn't seem to happen. In fact, it seems more like the following is happening during the rebase:
> 1) detach HEAD
> 2) rebase
> 3) reattach to <branch>
>
> If <branch> is HEAD, then is does nothing and remains detached.
> I find this behavior confusing since I would expect it to return to whatever HEAD was pointing to at the start of the command, such as my branch. Also, the documentation says that the <branch> parameter defaults to HEAD, so passing 'HEAD' explicitly should result in the same behavior as not passing it:
> <branch> Working branch; defaults to HEAD.

You are right, it is probably a bug.
I guess usually people just use "git rebase -i HEAD~2" or "git rebase
-i master" and don't give the [<branch>] argument when using -i.

If you are interested in helping us debug this you might first want to
check if older git versions behaved like this.

Thanks,
Christian.

  parent reply	other threads:[~2015-12-22 21:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22 17:53 Git Rebase Issue Pierre-Luc Loyer
2015-12-22 19:25 ` Junio C Hamano
2015-12-22 21:02 ` Christian Couder [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-03-13 12:35 git rebase issue Andy Shevchenko
2023-03-13 12:58 ` Andy Shevchenko
2023-03-20 12:10   ` Andy Shevchenko
2023-03-20 14:41     ` Felipe Contreras
2023-03-20 17:01     ` Jeff King
2023-03-20 17:20       ` Andy Shevchenko
2023-03-23 20:37         ` Felipe Contreras
2023-03-24  7:52           ` Andy Shevchenko

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='CAP8UFD3F6+VRyEF6XuxUcC_qiY7k4a-g8J-NKBZWDk=1=m1=WA@mail.gmail.com' \
    --to=christian.couder@gmail.com \
    --cc=Pierre-Luc.Loyer@bhvr.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).