Subject: Re: [PATCH v3] promisor-remote: skip move_to_tail when no-op

From: Jeff King <[email-masked]>
Date: Mon, 30 Sep 2019 17:27:58 -0400

On Mon, Sep 30, 2019 at 01:28:18PM -0700, Emily Shaffer wrote:

> Previously, when promisor_remote_move_to_tail() is called for a
> promisor_remote which is currently the final element in promisors, a
> cycle is created in the promisors linked list. This cycle leads to a
> double free later on in promisor_remote_clear() when the final element
> of the promisors list is removed: promisors is set to promisors->next (a
> no-op, as promisors->next == promisors); the previous value of promisors
> is free()'d; then the new value of promisors (which is equal to the
> previous value of promisors) is also free()'d. This double-free error
> was unrecoverable for the user without removing the filter or re-cloning
> the repo and hoping to miss this edge case.
> 
> Now, when promisor_remote_move_to_tail() would be a no-op, just do a
> no-op. In cases of promisor_remote_move_to_tail() where r is not already
> at the tail of the list, it works as before.
> 
> Helped-by: Jeff King <[email-masked]>
> Signed-off-by: Emily Shaffer <[email-masked]>
> ---
> Fixed up some nits from Peff in v2. Thanks especially for the catch on
> capturing the output of the fetch - I had been grepping it before I
> realized that test_must_fail accounted for unexpected signal exits, and
> forgot to remove the redirect.

Thanks, this looks pretty good, except one little thing:

> +test_expect_success 'single promisor remote can be re-initialized gracefully' '
> +	# ensure one promisor is in the promisors list
> +	rm -rf repo &&
> +	test_create_repo repo &&
> +	test_create_repo other &&
> +	git -C repo remote add foo "file://$(pwd)/other" &&
> +	git -C repo config remote.foo.promisor true &&
> +	git -C repo config extensions.partialclone foo &&
> +
> +	# reinitialize the promisors list; this must fail gracefully
> +	git -C repo fetch --filter=blob:none foo
> +'

We expect this to succeed now, so "this must fail gracefully" no longer
applies, right?

-Peff