Re: What's cooking in git.git (Mar 2017, #02; Fri, 3)

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2017, 17:43 UTC
Message-ID: <xmqqd1dasez2.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <BA6E546F-3594-4673-A43B-7E4D4CEA8F68@gmail.com>

Lars Schneider <larsxschneider@gmail.com> writes:

> Agreed. Would it be OK to store the "delayed" bit in the cache
> entry itself? The extended ce_flags are stored on disk which is not
> necessary I think. Would a new member in the cache_entry struct be
> an acceptable option?

I'd imagine that those with thousands of cache entries in their index prefer not to bloat sizeof(struct cache_entry) for something like this, that is _only_ used during the write-out phase. Would a new pointer in the "struct checkout" that points at whatever data structure you need (perhaps a "string_list"?) work? As long as the pointer points at a constant thing, you may not even have to loosen the constness of "struct checkout *" itself?

Show 9 quoted lines

>> Within such a framework, your checkout_delayed_entries() would be a
>> special case for finalizing a "struct checkout" that has been in
>> use.  By enforcing that any "struct checkout" begins its life by a
>> "state = CHECKOUT_INIT" initialization and finishes its life by a
>> "finish_checkout(&state)" call, we will reduce risks to forget
>> making necessary call to checkout_delayed_entries(), I would think.
>
> Agreed. How would you want to enforce "finish_checkout(&state)", though?
> By convention or by different means?

We can start with "convention", just like "if you did STRBUF_INIT, you must do strbuf_release() at some point" has served us well, I would think.

Thanks.