Re: [PATCH v3] promisor-remote: skip move_to_tail when no-op
- From
Jeff King <peff@peff.net>
- Date
- Sep 30, 2019, 21:27 UTC
- Message-ID
- <20190930212758.GA18708@sigill.intra.peff.net>
- In-Reply-To
- <20190930202818.2172-1-emilyshaffer@google.com>
On Mon, Sep 30, 2019 at 01:28:18PM -0700, Emily Shaffer wrote:
Show 22 quoted lines
> 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 <peff@peff.net> > Signed-off-by: Emily Shaffer <emilyshaffer@google.com> > --- > 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:
Show 12 quoted lines
> +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