From: Lars Schneider <larsxschneider@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Mar 2017, #02; Fri, 3)
Date: Wed, 22 Mar 2017 08:08:57 +0100 [thread overview]
Message-ID: <10A7B711-C5C7-4F57-AF08-E748FB35FD0C@gmail.com> (raw)
In-Reply-To: <xmqqd1dasez2.fsf@gitster.mtv.corp.google.com>
> On 21 Mar 2017, at 18:43, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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?
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
prev parent reply other threads:[~2017-03-22 7:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-03 23:26 What's cooking in git.git (Mar 2017, #02; Fri, 3) Junio C Hamano
2017-03-04 14:35 ` Stephan Beyer
2017-03-05 16:04 ` Pranit Bauva
2017-03-04 17:32 ` Lars Schneider
2017-03-06 21:08 ` Junio C Hamano
2017-03-21 8:28 ` Lars Schneider
2017-03-21 17:43 ` Junio C Hamano
2017-03-22 7:08 ` Lars Schneider [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10A7B711-C5C7-4F57-AF08-E748FB35FD0C@gmail.com \
--to=larsxschneider@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).