Duy Nguyen <pclouds@xxxxxxxxx> writes:
> On Wed, Feb 06, 2019 at 10:25:25AM +0000, Luke Diamand wrote:
>> I've recently started seeing a lot of this message when doing a rebase:
>>
>> warning: could not freshen shared index
>> '/home/ldiamand/git/dev_full/.git/worktrees/gcc8-take-2/sharedindex.0000000000000000000000000000000000000000'
>
> There are only two places in the code that could print this. The one
> in read_index_from() can't happen unless is_null_oid() is broken (very
> very unlikely).
>
> The other one is in write_locked_index() which could happen in theory
> but I don't understand how it got there. If you could build git, could
> you try this patch and see if it helps?
... meaning, if it hides the symptom, we'd know the codepath that
causes a NULL si->base_oid to appear here is the culprit? Or do you
mean that it is expected si->base_oid sometimes is NULL and we should
have been pretending as if si were NULL (i.e. split_index is not being
used)?
I take it as the latter (i.e. "helps" to narrow down the bug hunting
field, not "helps" by fixing the bug).
Thanks.
>
> -- 8< --
> diff --git a/read-cache.c b/read-cache.c
> index f68b367613..5ad71478dc 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -3165,6 +3165,7 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
> fill_fsmonitor_bitmap(istate);
>
> if (!si || alternate_index_output ||
> + (si && is_null_oid(&si->base_oid)) ||
> (istate->cache_changed & ~EXTMASK)) {
> if (si)
> oidclr(&si->base_oid);
> -- 8< --
>
>
>> (There's a repo called dev_full, and I've got a worktree where I'm
>> working on my 3rd attempt to make it work with gcc8).
>>
>> That file doesn't actually exist but there are a bunch of
>> sharedindex.XXX files in there with more convincing looking names.
>>
>> 2.20.1.611.gfbb209baf1
> --
> Duy
