Re: could not freshen shared index ..../sharedindex.0000000000000000000000000000000000000000'
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 8, 2019, 17:23 UTC
- Message-ID
- <xmqqzhr6kxcj.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20190208100221.GA22283@ash>
Duy Nguyen <pclouds@gmail.com> writes:
Show 13 quoted lines
> 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.
Show 26 quoted lines
>
> -- 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