> On 21 Mar 2017, at 18:43, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Lars Schneider <larsxschneider@xxxxxxxxx> 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? OK. I will try that and post a new round soonish. > >>> 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