git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [1.8.0] Summary of the discussions

From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date
Feb 18, 2011, 02:08 UTC
Message-ID
<alpine.DEB.2.00.1102172033340.14950@debian>
In-Reply-To
<7vwrky5f48.fsf@alter.siamese.dyndns.org>
On Thu, 17 Feb 2011, Junio C Hamano wrote:
Show 10 quoted lines
>  * "git checkout refs/heads/<name>" checks out <name> branch.
> 
>     From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
>     Date: Mon, 7 Feb 2011 06:01:51 -0500 (EST)
>     Message-ID: <alpine.DEB.1.10.1102062234010.3788@debian>
> 
>     -- summary --
> 
>     In addition to "git checkout <name>" that names an existing branch,
>     special case "git checkout refs/heads/<name>" to check the branch out,

At first I was going to say that I don't think special casing it should be necessary. It seemed like as long as the name resolves to something like refs/heads/<name>, the branch should be checked out. Then I think I realized why you said to special case it. Since checkout favors branches to tags, we would first have to check if refs/heads/<arg> is valid and if it is not, check if the argument resolves to refs/heads/<name> (maybe ignoring tags called "heads/<name>").

Show 17 quoted lines
>     instead of detaching HEAD at the tip of the branch.  If you want to
>     detach at a specific commit and wanted to disambiguate <name> that is
>     both a branch and another ref by checking out refs/heads/<name>, your
>     workflow will be broken by this change, but you can still say
>     refs/heads/<name>^0 to work it around.
> 
>     -- comments --
> 
>     I do not think this backward incompatible breakage would seriously
>     hurt in practice, and if people see newbies are hurt by getting a
>     detached HEAD when they check out refs/heads/<name>, this proposal
>     might be an improvement, but I have a feeling that this may be trying
>     to solve a wrong problem.
> 
>     Why are these people _tempted_ to type refs/heads/ explicitly?  It
>     could be our tutorial or documentation.  That might be the thing to
>     fix.

It wasn't until recently that I learned that "git checkout [refs/]heads/<name>" (and rebase <upstream> [refs/]heads/name) detaches the head, so it wasn't really to try to help newbies that I proposed changing it. It was just that the current behavior is not what I think most people would expect.

/Martin
Previous: Junio C HamanoNext: Jens Lehmann
Message 2 of 14 in “[1.8.0] Summary of the discussions”
  1. Junio C HamanoFeb 18, 2011
  2. Martin von ZweigbergkFeb 18, 2011
  3. [1.7.5] Let fetch and pull recurse into submodules when new commits are recordedJens Lehmann, Feb 19, 2011
  4. Marc BranchaudFeb 21, 2011
  5. Jens LehmannFeb 21, 2011
  6. [1.8.0] Recursively checkout, merge and reset populated submodulesJens Lehmann, Feb 19, 2011
  7. Junio C HamanoFeb 20, 2011
  8. Marc BranchaudFeb 21, 2011
  9. Jens LehmannFeb 21, 2011
  10. Marc BranchaudFeb 21, 2011
  11. Jens LehmannFeb 21, 2011
  12. Miles BaderFeb 22, 2011
  13. Phil HordFeb 22, 2011
  14. Jens LehmannFeb 22, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.