All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 01/14] oidtree: modernize the code a bit
Date: Mon, 23 Mar 2026 07:22:46 +0100	[thread overview]
Message-ID: <acDcNkIojSNiryFV@pks.im> (raw)
In-Reply-To: <ab3KjF_1WW7hQBaA@fruit.crustytoothpaste.net>

On Fri, Mar 20, 2026 at 10:30:36PM +0000, brian m. carlson wrote:
> On 2026-03-20 at 06:40:10, Patrick Steinhardt wrote:
> > On Thu, Mar 19, 2026 at 09:08:44AM -0700, Junio C Hamano wrote:
> > > I know the original also used GIT_MAX_HEXSZ to clamp the length for
> > > sanity, but because we know what algorithm is in use, I wonder if we
> > > want to use the limit more specific to it.
> > 
> > That assumes that the passed prefix OID actually has an algorithm
> > attached to it, and that may not be the case. We could initialize the
> > overall oidtree with a hash algorithm in `oidtree_init()`, and if so we
> > can then become a bit more thorough with our asserts.
> >
> > But I feel like that would go beyond the smallish cleanups that I'm
> > doing in this patch.
> 
> We should stop assuming that a zero `algo` field in `struct object_id`
> means `the_hash_algo` because that makes libification hard and our Rust
> code doesn't support it (because accessing mutable globals without a
> lock is unsafe)[0].  So in general, I would be fine with forcing callers
> to set an algorithm per OID, both here and elsewhere in our code.
> 
> However, I am also fine with doing that in a different series for the
> sake of minimalism in this one.  I will probably get to that at some
> point if nobody else does.

Yeah, I fully agree that we should get rid of this assumption. Thanks!

Patrick

  reply	other threads:[~2026-03-23  6:22 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19  6:52 [PATCH 00/14] odb: generic object name handling Patrick Steinhardt
2026-03-19  6:52 ` [PATCH 01/14] oidtree: modernize the code a bit Patrick Steinhardt
2026-03-19 16:08   ` Junio C Hamano
2026-03-20  6:40     ` Patrick Steinhardt
2026-03-20 22:30       ` brian m. carlson
2026-03-23  6:22         ` Patrick Steinhardt [this message]
2026-03-19  6:53 ` [PATCH 02/14] oidtree: extend iteration to allow for arbitrary return codes Patrick Steinhardt
2026-03-19 16:27   ` Junio C Hamano
2026-03-20  6:40     ` Patrick Steinhardt
2026-03-19 16:27   ` Karthik Nayak
2026-03-19  6:53 ` [PATCH 03/14] odb: introduce `struct odb_for_each_object_options` Patrick Steinhardt
2026-03-19 14:25   ` Junio C Hamano
2026-03-19 14:59     ` Patrick Steinhardt
2026-03-20  9:01   ` Karthik Nayak
2026-03-19  6:53 ` [PATCH 04/14] object-name: move logic to iterate through loose prefixed objects Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 05/14] object-name: move logic to iterate through packed " Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 06/14] object-name: extract function to parse object ID prefixes Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 07/14] object-name: backend-generic `repo_collect_ambiguous()` Patrick Steinhardt
2026-03-19 14:26   ` Junio C Hamano
2026-03-19 14:59     ` Patrick Steinhardt
2026-03-20  9:23   ` Karthik Nayak
2026-03-19  6:53 ` [PATCH 08/14] object-name: backend-generic `get_short_oid()` Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 09/14] object-name: merge `update_candidates()` and `match_prefix()` Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 10/14] object-name: abbreviate loose object names without `disambiguate_state` Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 11/14] object-name: simplify computing common prefixes Patrick Steinhardt
2026-03-20 10:01   ` Karthik Nayak
2026-03-20 10:30     ` Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 12/14] object-name: move logic to compute loose abbreviation length Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 13/14] object-file: move logic to compute packed " Patrick Steinhardt
2026-03-19  6:53 ` [PATCH 14/14] odb: introduce generic `odb_find_abbrev_len()` Patrick Steinhardt
2026-03-20  7:07 ` [PATCH v2 00/14] odb: generic object name handling Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 01/14] oidtree: modernize the code a bit Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 02/14] oidtree: extend iteration to allow for arbitrary return codes Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 03/14] odb: introduce `struct odb_for_each_object_options` Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 04/14] object-name: move logic to iterate through loose prefixed objects Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 05/14] object-name: move logic to iterate through packed " Patrick Steinhardt
2026-03-30 17:55     ` Toon Claes
2026-03-20  7:07   ` [PATCH v2 06/14] object-name: extract function to parse object ID prefixes Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 07/14] object-name: backend-generic `repo_collect_ambiguous()` Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 08/14] object-name: backend-generic `get_short_oid()` Patrick Steinhardt
2026-03-30 15:12     ` Toon Claes
2026-03-20  7:07   ` [PATCH v2 09/14] object-name: merge `update_candidates()` and `match_prefix()` Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 10/14] object-name: abbreviate loose object names without `disambiguate_state` Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 11/14] object-name: simplify computing common prefixes Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 12/14] object-name: move logic to compute loose abbreviation length Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 13/14] object-file: move logic to compute packed " Patrick Steinhardt
2026-03-20  7:07   ` [PATCH v2 14/14] odb: introduce generic `odb_find_abbrev_len()` Patrick Steinhardt
2026-03-20 10:04   ` [PATCH v2 00/14] odb: generic object name handling Karthik Nayak
2026-03-20 10:30     ` Patrick Steinhardt
2026-03-30 20:35       ` Toon Claes
2026-03-30 21:01         ` Junio C Hamano
2026-03-31  6:04         ` 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=acDcNkIojSNiryFV@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    /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.