All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Julia Evans <julia@jvns.ca>
Cc: "D. Ben Knoble" <ben.knoble@gmail.com>,
	 Julia Evans via GitGitGadget <gitgitgadget@gmail.com>,
	 git@vger.kernel.org,
	 Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Subject: Re: [PATCH v4] doc: checkout: rewrite detached HEAD state explanation
Date: Thu, 12 Nov 2026 07:40:22 -0800	[thread overview]
Message-ID: <xmqq5wy2kqhl.fsf@gitster.g> (raw)
In-Reply-To: <ddc6d42c-6e40-46a5-bb70-f89f11525ac4@jvns.ca> (Julia Evans's message of "Wed, 11 Nov 2026 16:45:34 -0500")

Julia Evans <julia@jvns.ca> writes:

> Yeah I agree the "it's the parent of the next commit" would be 
> distracting unless there's a specific reason we need to include it.
>
> I agree "the state from which your current changes started" isn't right 
> but I think if we reinterpret it as "the current commit you have checked 
> out" (which I think has the same or a very similar meaning) then it'll 
> seem familiar to folks and might even help.
> ...
> because I couldn't think of a reason why someone would clobber an 
> existing branch to check out an old version of their code.

When I find something interesting in a topic, which may be an old
commit from the point of view of 'seen', I would detach HEAD at the
tip of the branch to take a look at its contents, because what I am
going to do next would very often involve modifying the working tree
files to experiment.  Even a topic that is documentation only, like
the je/doc-detached-head topic, can have a cascading effect that
ends up breaking tests, for example, and I'd be futzing with the
sources and tests to figure out what the best fix would be.  Even
though I am not going to make any permanent commits out of these
efforts, being able to make temporary commits to mark a resumable
state is handy, and when my spelunking gets longer, I do make such
commits.

But of course, I do *not* want to contaminate the topic branch I
have been looking at.  The work I do, whether it is for validation
or for satisfying my own curiosity, does not necessarily align with
the objective the topic author had in mind when they wrote it.

This is where detached HEAD is the perfect mechanism to take
advantage of.  You do not want to clobber the branch you are going
to start your journey at, yet you want to be able to make tentative
changes to experiment, and you want to be able to take snapshots.

And during the journey, your HEAD points at a commit from which your
current changes started and points at a commit your next commit will
record as its parent.

I guess it requires a developer's mindset and imagination to
appreciate why detached HEAD is useful while spelunking.  We often
phrase the act of visiting random commits (often older ones) as
"sight-seeing", but in reality, even when you are mostly looking,
you do want to futz with things you see there.

It is in a developer's heart ;-).

Hope this clarifies.

  parent reply	other threads:[~2026-11-12 15:40 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 14:52 [PATCH] doc: checkout: rewrite detached HEAD state explanation Julia Evans via GitGitGadget
2026-10-07 16:43 ` Junio C Hamano
2026-10-13 12:54   ` Julia Evans
2026-10-19 14:05   ` Julia Evans
2026-10-19 21:24     ` Junio C Hamano
2026-10-20 12:52       ` Julia Evans
2026-10-20 13:06         ` Julia Evans
2026-10-07 19:02 ` Kristoffer Haugsbakk
2026-10-13 11:48   ` Julia Evans
2026-10-13 12:20     ` Kristoffer Haugsbakk
2026-10-13 12:27       ` Julia Evans
2026-10-13 12:42         ` Julia Evans
2026-10-13 13:01 ` [PATCH v2] " Julia Evans via GitGitGadget
2026-10-14 18:52   ` Junio C Hamano
2026-10-14 21:10     ` Julia Evans
2026-10-15 20:58 ` [PATCH v3] " Julia Evans via GitGitGadget
2026-10-15 22:39   ` Junio C Hamano
2026-10-16 14:55     ` Julia Evans
2026-10-16 17:03       ` Junio C Hamano
2026-10-16 18:35         ` Julia Evans
2026-10-16 19:05           ` Junio C Hamano
2026-10-16 19:03 ` [PATCH v4] " Julia Evans via GitGitGadget
2026-10-16 21:10   ` Junio C Hamano
2026-11-07 20:06     ` D. Ben Knoble
2026-11-08  4:25       ` Junio C Hamano
2026-11-09 21:48         ` Julia Evans
2026-11-10  6:46           ` Junio C Hamano
2026-11-10 13:13             ` Julia Evans
2026-11-11 21:45       ` Julia Evans
2026-11-12  1:58         ` Ben Knoble
2026-11-12 15:40         ` Junio C Hamano [this message]
2026-11-12 16:37           ` Julia Evans
2026-11-12 19:25             ` Junio C Hamano
2026-11-12 22:45               ` Julia Evans
2026-10-16 22:02   ` Junio C Hamano
2026-11-11 21:34 ` [PATCH v5] " Julia Evans via GitGitGadget
2026-11-11 23:14   ` Junio C Hamano
2026-11-12  0:01     ` Julia Evans
2026-11-12  4:08     ` Junio C Hamano
2026-11-12 22:47 ` [PATCH v6] " Julia Evans via GitGitGadget

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=xmqq5wy2kqhl.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=julia@jvns.ca \
    --cc=kristofferhaugsbakk@fastmail.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.