On Fri, Jul 11, 2025 at 05:25:51AM -0500, Karthik Nayak wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > > When a repository is configured to have a compatibility hash algorithm > > we keep track of object ID mappings for loose objects via the loose > > object map. This map simply maps an object ID of the actual hash to the > > object ID of the compatibility hash. This loose object map is an > > inherent property of the loose files backend and thus of one specific > > object source. > > > > Refactor the interfaces to reflect this by requiring a `struct > > odb_source` as input instead of a repository. This prepares for > > subsequent commits where we will refactor writing of loose objects to > > work on a `struct odb_source`, as well. > > > > Signed-off-by: Patrick Steinhardt <ps@xxxxxx> > > --- > > loose.c | 16 +++++++++------- > > loose.h | 4 +++- > > object-file.c | 6 +++--- > > 3 files changed, 15 insertions(+), 11 deletions(-) > > > > diff --git a/loose.c b/loose.c > > index 519f5db7935..e8ea6e7e24b 100644 > > --- a/loose.c > > +++ b/loose.c > > @@ -166,7 +166,8 @@ int repo_write_loose_object_map(struct repository *repo) > > return -1; > > } > > > > -static int write_one_object(struct repository *repo, const struct object_id *oid, > > +static int write_one_object(struct odb_source *source, > > Nit: In one of the earlier commits, we renamed a function working on a > particular source to have the '_source' suffix. Should we do the same > here? > > I understand that this is related to a specific source (loose files) and > probably would move into its own file under the objects namespace. But > perhaps something to think about. Yeah, things are still wildly inconsistent right now. This will change once we can finally carve out the actual object source backends, at which point we'll have to move around a bunch of functions anyway. So I'm not yet polishing up every function. Patrick
