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
prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.