Re: [PATCH v2 3/4] t5300: move --window clamp test next to unclamped

> > So this may become more real in the future. I wonder if there is a way
> > to add a test to future-proof against changes to how the quarantine
> > system works. The theoretical problem case is if we did quarantine
> > fetches, but accidentally wrote the new promisor pack into the main
> > repo instead of the quarantine, and then a fetch rejected the incoming
> > pack (because of a hook, failed connectivity check, etc). Then we'd end
> > up with the new promisor pack when we shouldn't, which I guess could
> > move objects from that incoming pack that we rejected into the main
> > repo, despite the quarantine?
> > 
> > I can't think of a way to test that now, without the quarantine-on-fetch
> > feature existing.
> 
> Quarantine on fetch does seem like a good idea. I also can't think of
> a way to test that now. Although, for the fetch case, my patch set is
> not the first time that an extra packfile (that is, a packfile not in
> the "packfile" section of the fetch response) could be written during
> a fetch: packfile-uris and bundle-uris already exist. So I would hope
> that the implementor of the fetch quarantine feature would be aware of
> at least one of these extra features, and design the test to check that
> absolutely no packfiles are written if the fetch is rejected. (So I
> don't think the future needs to be "proofed" so much.)