From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: "Maciej Ciemborowicz" <maciej.ciemborowicz@gmail.com>,
git@vger.kernel.org, "Patrick Steinhardt" <ps@pks.im>,
"Phil Hord" <phil.hord@gmail.com>,
"Elijah Newren" <newren@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"D . Ben Knoble" <ben.knoble@gmail.com>
Subject: Re: [PATCH v5 1/3] refs: allow callers to supply old OIDs for batch deletion
Date: Thu, 24 Sep 2026 09:34:47 -0700 [thread overview]
Message-ID: <xmqq8q4q4nh4.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZTWq6eiqCwUyUhCffTn1=f9pdAip7nsYJMnaPPUuccB8g@mail.gmail.com> (Karthik Nayak's message of "Thu, 24 Sep 2026 03:04:59 -0700")
Karthik Nayak <karthik.188@gmail.com> writes:
> I'm also still of the opinion that this shouldn't be done. A zeroed out
> null_oid is usually a user bug, where they haven't initialized a `struct
> object_id` correctly or ignored the return code while reading a ref.
... unless they are using an element in an object_array and want to
selectively have object names to some but not all of the elements in
the array. In such a use case, a pointer to a null_oid is just as
good a representation as a NULL pointer of "N/A" for a parameter to
a function like this one that takes an optional object name. You
could force each such callers to notice the entry they are about to
call this function with has a null_oid and pass a NULL instead, but
why force the caller to do so when the callee is capable of doing so
centrally?
next prev parent reply other threads:[~2026-09-24 16:34 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 13:34 [BUG] reference-transaction reports zero OIDs for branch and tag deletion Maciej Ciemborowicz
2026-09-19 14:59 ` D. Ben Knoble
2026-09-19 15:42 ` Maciej Ciemborowicz
2026-09-19 20:11 ` [PATCH 0/3] refs: report old OIDs for batched deletions Maciej Ciemborowicz
2026-09-19 20:11 ` [PATCH 1/3] refs: allow callers to supply old OIDs for batch deletion Maciej Ciemborowicz
2026-09-19 20:41 ` Karthik Nayak
2026-09-20 10:38 ` Maciej Ciemborowicz
2026-09-20 10:54 ` [PATCH v2 0/3] refs: report old OIDs for batched deletions Maciej Ciemborowicz
2026-09-20 10:54 ` [PATCH v2 1/3] refs: allow callers to supply old OIDs for batch deletion Maciej Ciemborowicz
2026-09-21 13:12 ` Karthik Nayak
2026-09-21 23:55 ` Junio C Hamano
2026-09-20 10:54 ` [PATCH v2 2/3] branch, tag: retain old OIDs in batched deletions Maciej Ciemborowicz
2026-09-21 13:19 ` Karthik Nayak
2026-09-20 10:54 ` [PATCH v2 3/3] fetch, remote: retain old OIDs when pruning refs Maciej Ciemborowicz
2026-09-21 13:56 ` Karthik Nayak
2026-09-21 13:57 ` [PATCH v2 0/3] refs: report old OIDs for batched deletions Karthik Nayak
2026-09-21 20:01 ` Maciej Ciemborowicz
2026-09-22 12:26 ` [PATCH v3 " Maciej Ciemborowicz
2026-09-22 12:26 ` [PATCH v3 1/3] refs: allow callers to supply old OIDs for batch deletion Maciej Ciemborowicz
2026-09-22 18:55 ` Junio C Hamano
2026-09-22 19:21 ` Maciej Ciemborowicz
2026-09-22 23:31 ` Junio C Hamano
2026-09-22 12:26 ` [PATCH v3 2/3] branch, tag: retain old OIDs in batched deletions Maciej Ciemborowicz
2026-09-22 12:26 ` [PATCH v3 3/3] fetch, remote: retain old OIDs when pruning refs Maciej Ciemborowicz
2026-09-22 19:16 ` Junio C Hamano
2026-09-22 22:29 ` [PATCH v4 0/3] refs: report old OIDs for batched deletions Maciej Ciemborowicz
2026-09-22 22:31 ` [PATCH v4 1/3] refs: allow callers to supply old OIDs for batch deletion Maciej Ciemborowicz
2026-09-22 22:31 ` [PATCH v4 2/3] branch, tag: retain old OIDs in batched deletions Maciej Ciemborowicz
2026-09-22 22:31 ` [PATCH v4 3/3] fetch, remote: retain old OIDs when pruning refs Maciej Ciemborowicz
2026-09-23 20:03 ` Junio C Hamano
2026-09-23 21:02 ` Maciej Ciemborowicz
2026-09-23 21:04 ` [PATCH v5 0/3] refs: report old OIDs for batched deletions Maciej Ciemborowicz
2026-09-23 21:04 ` [PATCH v5 1/3] refs: allow callers to supply old OIDs for batch deletion Maciej Ciemborowicz
2026-09-24 10:04 ` Karthik Nayak
2026-09-24 16:34 ` Junio C Hamano [this message]
2026-09-24 19:43 ` Maciej Ciemborowicz
2026-09-24 11:07 ` Patrick Steinhardt
2026-09-24 16:45 ` Junio C Hamano
2026-09-24 20:13 ` Maciej Ciemborowicz
2026-09-28 6:44 ` Patrick Steinhardt
2026-09-28 6:43 ` Patrick Steinhardt
2026-09-24 19:56 ` Maciej Ciemborowicz
2026-09-23 21:04 ` [PATCH v5 2/3] branch, tag: retain old OIDs in batched deletions Maciej Ciemborowicz
2026-09-24 11:08 ` Patrick Steinhardt
2026-09-23 21:04 ` [PATCH v5 3/3] fetch, remote: retain old OIDs when pruning refs Maciej Ciemborowicz
2026-09-23 21:55 ` [PATCH v5 0/3] refs: report old OIDs for batched deletions Junio C Hamano
2026-09-24 22:33 ` [PATCH v6 0/1] refs: report old values to transaction hooks Maciej Ciemborowicz
2026-09-24 22:33 ` [PATCH v6 1/1] " Maciej Ciemborowicz
2026-09-30 3:11 ` Maciej Ciemborowicz
2026-10-01 17:37 ` Maciej Ciemborowicz
2026-09-19 20:11 ` [PATCH 2/3] branch, tag: retain old OIDs in batched deletions Maciej Ciemborowicz
2026-09-19 20:11 ` [PATCH 3/3] fetch, remote: retain old OIDs when pruning refs Maciej Ciemborowicz
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=xmqq8q4q4nh4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=maciej.ciemborowicz@gmail.com \
--cc=newren@gmail.com \
--cc=phil.hord@gmail.com \
--cc=ps@pks.im \
/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.