Re: [PATCH v2] object-file: reprepare alternates when necessary

From: Jonathan Tan <jonathantanmy@google.com>
Date: Mar 11, 2023, 03:09 UTC
Message-ID: <20230311030923.4171623-1-jonathantanmy@google.com>
In-Reply-To: <xmqqilf8yx3k.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> Jonathan Tan <jonathantanmy@google.com> writes:
> 
> > But I guess clearing a linked list and hashmap can be a bit cumbersome
> > in C, so maybe it would be reasonable to assume that this behavior
> > would not change.
> 
> I think the original reason why we did not clear was because we
> never knew (and we do not know) what is still in use.

Ah, I meant that prepare_alt_odb() assumes that the data structures are as they were originally initialized. So I can think of at least 2 ways that we could implement prepare_alt_odb():

 (a) Repeatedly modify r->objects->odb_tail and repeatedly assign to
     kh_value(r->objects->odb_by_path, pos).
 (b) Call make_odb(), which returns a pointer that we assign to
     r->objects->odb, and call make_odb_hashmap(), which returns a
     pointer that we assign to r->objects->odb_by_path.

Remember that prepare_alt_odb() is meant to start from scratch, so it is reasonable to do either.

In Java, for example, it would be very reasonable to do (b). But this patch assumes that we have implemented it as (a). Indeed we have implemented it as (a) (although we have never documented it as such), and my quoted statement above is meant to say that it might be reasonable to keep assuming that it would be (a).