git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Dun Peal <dunpealer@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>, Git ML <git@vger.kernel.org>
Subject: Re: Proper way to checkout a tag?
Date: Thu, 02 Dec 2010 09:33:18 +0100	[thread overview]
Message-ID: <4CF759CE.5010705@drmicha.warpmail.net> (raw)
In-Reply-To: <AANLkTim=0dqH=gqbM1xQOWQPCZb78wfsn9wf5WRJJ9vt@mail.gmail.com>

Dun Peal venit, vidit, dixit 01.12.2010 21:16:
> On Wed, Dec 1, 2010 at 1:51 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> The idea is this: when you check out a tag or a remote-tracking
>> branch, it is not to make changes to it.  Tags are unchanging,
>> remote-tracking branches track remote state that the user does not
>> directly control.
> 
> Yes, users checkout a release tag just so they can build parts of it.
> There's definitely no intention of creating new changes on top of
> them, and if there is then it should properly be a head (branch).
> 
> I guess that's exactly the use-case for detached HEAD, so I guess the
> answer is that we should all stop being afraid of that superficially
> scary term.

It's really one of the most useful features of git (as Jonathan
explained). There are two things which make it scary:

- The name. We could call it differently (free head, unbound head,
branchless head, west coast head...).

- The garbage collection. It's easy to commit on top of a detached head
by mistake, and once you switch away from that, it's difficult to find
it again (reflog) and easy to lose (gc/prune).

Though the "throw-away" nature of detached heads is a useful feature, we
could possibly help users who commit on top of them better.

Michael

      reply	other threads:[~2010-12-02  8:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-01 19:38 Proper way to checkout a tag? Dun Peal
2010-12-01 19:51 ` Jonathan Nieder
2010-12-01 20:16   ` Dun Peal
2010-12-02  8:33     ` Michael J Gruber [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CF759CE.5010705@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=dunpealer@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /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.
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 NNTP newsgroup(s).