Re: [PATCH v3 10/21] read-cache: regenerate shared index if necessary

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 27, 2016, 19:08 UTC
Message-ID: <xmqqk2al9ocv.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20161226102222.17150-11-chriscool@tuxfamily.org>

Christian Couder <christian.couder@gmail.com> writes:

Show 7 quoted lines

> +	case 0:
> +		return 1; /* 0% means always write a new shared index */
> +	case 100:
> +		return 0; /* 100% means never write a new shared index */
> +	default:
> +		; /* do nothing: just use the configured value */
> +	}

Just like you did in 04/21, write "break" to avoid mistakes made in the future, i.e.

	default:
		break; /* just use the configured value */

Show 9 quoted lines

> +
> +	/* Count not shared entries */
> +	for (i = 0; i < istate->cache_nr; i++) {
> +		struct cache_entry *ce = istate->cache[i];
> +		if (!ce->index)
> +			not_shared++;
> +	}
> +
> +	return istate->cache_nr * max_split < not_shared * 100;

On a 32-bit arch with 2G int and more than 20 million paths in the index, multiplying by max_split that can come close to 100 can theoretically cause integer overflow, but in practice it probably does not matter. Or does it?