On Mon, Feb 27, 2017 at 11:43:46AM +0530, Karthik Nayak wrote: > On Mon, Feb 27, 2017 at 10:22 AM, Luc Van Oostenryck > <luc.vanoostenr...@gmail.com> wrote: > > Hi, > > > > I just discover something which very much seems a bug to me > > while making an error in renaming a branch. > > The scenario is the following: > > - I have a branch named 'orig' > > - I want to make some experimental changes on it: > > $ git checkout -b temp orig > > $ ... edit some files ... > > $ ... make some tests & commits ... > > - I'm happy with my changes, so I want to have my original > > branch to now points to the head of this temp branch > > but did it wrongly: > > $ git branch -m -f orig @ > > Here you are using the '-m' flag, which is to rename a branch. So what > you're essentially > doing is: > $ git branch -m -f orig HEAD > Do note that this won't reset 'orig' to point to 'HEAD', rather this > renames 'orig' to 'HEAD'. > > What you actually want to do (to reset 'orig' to 'HEAD') is: > $ git branch -f orig @ > This would make orig point to the current HEAD.
Regardless of the original intent, I think it is wrong to convert "@" to a branch named "HEAD". I think the bug is in strbuf_check_branch_ref(), which blindly sticks "refs/heads/" in front of any value we get from interpret_branch_name(), which clearly does not make sense for HEAD. -Peff