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

Lars Schneider [off-list ref] 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?

quoted

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.

On 21 Mar 2017, at 18:43, Junio C Hamano [off-list ref] wrote:

Lars Schneider [off-list ref] writes:

quoted

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?

OK. I will try that and post a new round soonish.

quoted

quoted

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.

OK!

Thanks,
Lars