{"thread":{"id":"41068","subject":"Git Rebase Issue","startedAt":"2015-12-22T17:53:42Z","lastAt":"2015-12-22T21:02:16Z","messageCount":3,"participants":["Pierre-Luc Loyer","Junio C Hamano","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"274901","messageId":"39E7EE9D306F544FAD3A0D16B7B7CAAD2C1E819D@mtlsvrmxwv02.A2M.com","threadId":"41068","inReplyTo":null,"subject":"Git Rebase Issue","fromName":"Pierre-Luc Loyer","fromEmail":"pierre-luc.loyer@bhvr.com","sentAt":"2015-12-22T17:53:42Z","receivedAt":"2015-12-22T17:53:42Z","isPatch":false,"sender":{"key":"pierre-luc.loyer@bhvr.com","avatar":null},"body":"Hi,\n\nI've encountered a situation using rebase for which I don't understand the results, even after reading the documentation.\nI'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\nFrom the documentation, I read that my second parameter (HEAD) is the parameter:\n\n   git rebase [-i | --interactive] [options] [--exec ] [--onto ]\n\n   [] []\n\n   If is specified, git rebase will perform an automatic git checkout before doing anything else. Otherwise it remains on the current branch.\n Working branch; defaults to HEAD.\n\n   Upon completion, will be the current branch.\n\nHere is a full example than can be used to easily repro the issue. Go to an empty folder.\ngit init\ngit echo text > file.txt\ngit add .\ngit commit -m \"Add file.txt\"\ngit echo text2 > file.txt\ngit commit -am \"Modify file.txt\"\ngit echo text3 > file.txt\ngit commit -am \"Remodify file.txt\"\n\nNow the interesting part:\n$ git rebase -i HEAD~2 HEAD\n[detached HEAD 9178b93] Modify file\n1 file changed, 1 insertion(+), 1 deletion(-)\nSuccessfully rebased and updated detached HEAD. \n\nFrom the documentation it says that (which is HEAD) will be checked out before doing anything and that upon completion, 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:\n1) detach HEAD\n2) rebase\n3) reattach to \n\nIf is HEAD, then is does nothing and remains detached.\nI 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 parameter defaults to HEAD, so passing 'HEAD' explicitly should result in the same behavior as not passing it:\n Working branch; defaults to HEAD.\n\nPierre-Luc Loyer\n"},{"id":"274910","messageId":"xmqqwps6cmkf.fsf@gitster.mtv.corp.google.com","threadId":"41068","inReplyTo":"39E7EE9D306F544FAD3A0D16B7B7CAAD2C1E819D@mtlsvrmxwv02.A2M.com","subject":"Re: Git Rebase Issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-22T19:25:52Z","receivedAt":"2015-12-22T19:25:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre-Luc Loyer writes:\n\n> From the documentation it says that (which is HEAD) will be checked out before doing anything and that upon completion, 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:\n> 1) detach HEAD\n> 2) rebase\n> 3) reattach to \n\nYou do not have to say \"HEAD\" for \"\", if you are rebasing\nthe current branch. Either leave it unsaid, or name the branch.\n\nPassing \"HEAD\" (or any of its variants that names the exact commit\nat the tip of the current branch, without using the name of the\ncurrent branch, e.g. \"master^0\") as the \"branch to rebase\" is an\nadvanced technique to use when you want to avoid messing with the\nbranch itself. It is deliberate that the HEAD is left detached.\n\nYou'd (once you learn Git sufficently and got comfortable with\nworking on a detached HEAD, that is) often find yourself doing\nthings like this:\n\n1. rebase temporarily on detached HEAD\n\n $ git rebase -i HEAD~2 HEAD ;# amend the tip two\n\n2. double check the result and convince yourself that it is better\n than the original\n\n $ git diff master HEAD\n\n $ git log master.. >updated\n $ git log -2 master >original\n $ diff -u original updated\n\n3-a. once satisfied, update the branch\n\n $ git checkout -B master\n\n3-b. or abandon if the result is undesirable.\n\n $ git checkout master\n"},{"id":"274916","messageId":"CAP8UFD3F6+VRyEF6XuxUcC_qiY7k4a-g8J-NKBZWDk=1=m1=WA@mail.gmail.com","threadId":"41068","inReplyTo":"39E7EE9D306F544FAD3A0D16B7B7CAAD2C1E819D@mtlsvrmxwv02.A2M.com","subject":"Re: Git Rebase Issue","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-12-22T21:02:16Z","receivedAt":"2015-12-22T21:02:16Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Tue, Dec 22, 2015 at 6:53 PM, Pierre-Luc Loyer\n wrote:\n> Hi,\n>\n> I've encountered a situation using rebase for which I don't understand the results, even after reading the documentation.\n> 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\n> From the documentation, I read that my second parameter (HEAD) is the parameter:\n>\n> git rebase [-i | --interactive] [options] [--exec ] [--onto ]\n>\n> [] []\n>\n> If is specified, git rebase will perform an automatic git checkout before doing anything else. Otherwise it remains on the current branch.\n> Working branch; defaults to HEAD.\n>\n> Upon completion, will be the current branch.\n>\n> Here is a full example than can be used to easily repro the issue. Go to an empty folder.\n> git init\n> git echo text > file.txt\n> git add .\n> git commit -m \"Add file.txt\"\n> git echo text2 > file.txt\n> git commit -am \"Modify file.txt\"\n> git echo text3 > file.txt\n> git commit -am \"Remodify file.txt\"\n>\n> Now the interesting part:\n> $ git rebase -i HEAD~2 HEAD\n> [detached HEAD 9178b93] Modify file\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> Successfully rebased and updated detached HEAD.\n>\n> From the documentation it says that (which is HEAD) will be checked out before doing anything and that upon completion, 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:\n> 1) detach HEAD\n> 2) rebase\n> 3) reattach to \n>\n> If is HEAD, then is does nothing and remains detached.\n> 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 parameter defaults to HEAD, so passing 'HEAD' explicitly should result in the same behavior as not passing it:\n> Working branch; defaults to HEAD.\n\nYou are right, it is probably a bug.\nI guess usually people just use \"git rebase -i HEAD~2\" or \"git rebase\n-i master\" and don't give the [] argument when using -i.\n\nIf you are interested in helping us debug this you might first want to\ncheck if older git versions behaved like this.\n\nThanks,\nChristian.\n"}]}