All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Ramsay Jones <ramsay@ramsayjones.plus.com>,
	 git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
	 Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: [PATCH v2 1/4] wt-status: read HEAD and ORIG_HEAD via the refdb
Date: Wed, 13 Dec 2023 07:15:33 -0800	[thread overview]
Message-ID: <xmqqmsuennfu.fsf@gitster.g> (raw)
In-Reply-To: <ZXlfeWtDgr1GQFCL@tanuki> (Patrick Steinhardt's message of "Wed, 13 Dec 2023 08:38:33 +0100")

Patrick Steinhardt <ps@pks.im> writes:

>> Me neither, but once you start thinking about getting rid of the
>> need to use one-file-per-ref filesystem, being able to maintain all
>> refs, including the pseudo refs, in one r/w store backend, becomes a
>> very tempting goal.  From that point of view, I do not have problem
>> with the idea to move _all_ pseudorefs to reftable.
>
> Yes, we're in agreement.
>
>> But I do have reservations on what Patrick, and the code he
>> inherited from Han-Wen, calls "special refs" (which is not defined
>> in the glossary at all), namely, refs.c:is_special_ref() and its
>> callers.
>
> I do not want to add "special refs" to the glossary because ultimately
> they should go away, with two exceptions: FETCH_HEAD and MERGE_HEAD.
> Once we're there we can of course discuss whether we want to explicitly
> point them out in the glossary and give them a special name.

OK, I somehow got a (wrong) impression that you are very close to
the finish line.  If the intention is to leave many others still in
the "special" category (for only the reasons of inertia), with a
vision that some selected few must remain "special" with their own
good reasons, then I am perfectly fine.

Thanks.

  reply	other threads:[~2023-12-13 15:15 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29  8:14 [PATCH 0/4] refs: improve handling of special refs Patrick Steinhardt
2023-11-29  8:14 ` [PATCH 1/4] wt-status: read HEAD and ORIG_HEAD via the refdb Patrick Steinhardt
2023-11-29 21:45   ` Taylor Blau
2023-11-30  7:42     ` Patrick Steinhardt
2023-11-30 17:36       ` Taylor Blau
2023-11-29  8:14 ` [PATCH 2/4] refs: propagate errno when reading special refs fails Patrick Steinhardt
2023-11-29 21:51   ` Taylor Blau
2023-11-30  7:43     ` Patrick Steinhardt
2023-11-29  8:14 ` [PATCH 3/4] refs: complete list of special refs Patrick Steinhardt
2023-11-29 21:59   ` Taylor Blau
2023-11-30  7:44     ` Patrick Steinhardt
2023-11-30 15:42   ` Phillip Wood
2023-12-01  6:43     ` Patrick Steinhardt
2023-12-04 14:18       ` Phillip Wood
2023-11-29  8:14 ` [PATCH 4/4] bisect: consistently write BISECT_EXPECTED_REV via the refdb Patrick Steinhardt
2023-11-29 22:13   ` Taylor Blau
2023-11-29 22:14 ` [PATCH 0/4] refs: improve handling of special refs Taylor Blau
2023-11-30  7:46   ` Patrick Steinhardt
2023-11-30 17:35     ` Taylor Blau
2023-12-12  7:18 ` [PATCH v2 " Patrick Steinhardt
2023-12-12  7:18   ` [PATCH v2 1/4] wt-status: read HEAD and ORIG_HEAD via the refdb Patrick Steinhardt
2023-12-12 20:24     ` Junio C Hamano
2023-12-12 23:32       ` Ramsay Jones
2023-12-13  0:36         ` Junio C Hamano
2023-12-13  7:38           ` Patrick Steinhardt
2023-12-13 15:15             ` Junio C Hamano [this message]
2023-12-14  9:04               ` Patrick Steinhardt
2023-12-14 16:41                 ` Junio C Hamano
2023-12-14 13:21       ` Patrick Steinhardt
2023-12-12  7:18   ` [PATCH v2 2/4] refs: propagate errno when reading special refs fails Patrick Steinhardt
2023-12-12 20:28     ` Junio C Hamano
2023-12-13  7:28       ` Patrick Steinhardt
2023-12-12  7:18   ` [PATCH v2 3/4] refs: complete list of special refs Patrick Steinhardt
2023-12-12  7:19   ` [PATCH v2 4/4] bisect: consistently write BISECT_EXPECTED_REV via the refdb Patrick Steinhardt
2023-12-14 13:36 ` [PATCH v3 0/4] refs: improve handling of special refs Patrick Steinhardt
2023-12-14 13:36   ` [PATCH v3 1/4] wt-status: read HEAD and ORIG_HEAD via the refdb Patrick Steinhardt
2023-12-14 13:37   ` [PATCH v3 2/4] refs: propagate errno when reading special refs fails Patrick Steinhardt
2023-12-14 13:37   ` [PATCH v3 3/4] refs: complete list of special refs Patrick Steinhardt
2023-12-14 13:37   ` [PATCH v3 4/4] bisect: consistently write BISECT_EXPECTED_REV via the refdb Patrick Steinhardt
2023-12-20 19:28   ` [PATCH v3 0/4] refs: improve handling of special refs Junio C Hamano
2023-12-21 10:08     ` Patrick Steinhardt

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=xmqqmsuennfu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=phillip.wood123@gmail.com \
    --cc=ps@pks.im \
    --cc=ramsay@ramsayjones.plus.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.