# Re: \[PATCH v2\] odb: do not list our own refs as alternate refs in the quarantine

- From: Kristofer Karlsson \<hidden\>
- Date: 2026-11-04 10:33:07 
- List: git
- Page: https://ratatoskr.run/git/2026/11/17859779
- Thread: https://ratatoskr.run/git/2026/10/17817793/t.md

```text
On Tue, 3 Nov 2026 at 22:53, Justin Tobler [ref] wrote:
>
> Regarding the fix proposed in this patch, I'm not quite sure this is
> really the right layer to address the problem. The root of the problem
> is that we are swapping around the "real" and quarantine object
> directories to facilitate writing to the "files" ODB transaction. IMO,
> this is already rather fragile. So I do agree with Patrick that I think
> the better long-term fix is to stop modifying the primary object
> directory altogether and instead propagate some context about the
> pending transaction via environment variables to the child process that
> it can use to reconstruct the proper environment. This is certainly a
> more involved change, but something that I've been wanting to do for a
> while now regardless.
>
> If we are interested in a more simple fix for the short-term, we could
> adapt `odb_transaction_env()` to have a "read-only" mode flag that does
> not modify the primary object directory and only appends the quarantine
> directory as an alternate. For the connectivity check in
> git-receive-pack(1) we don't write any object anyways, so configuring
> the environment in this manner should be sufficient to fix the issue.

I agree with that long-term direction.  What do you think we should
do for the short term?  I see a few options:
 1. A smaller, more focused patch in the alternate refs code, as Peff
   suggested in the other message.
 2. Your read-only transaction environment for the connectivity check,
   (if you want to take that on, I would probably mess it up :-) ).
 3. Only a regression test for now, with the hidden refs case marked as
   test_expect_failure, so that we do not lose track of it.
 4. Or nothing, and wait for the long-term fix, as nobody seems to be
   hit hard by this at the moment.

Thanks,
Kristofer
```