Re: [PATCH 0/2] commit-graph/server-info: use tempfile.h in more places
- From
Elijah Newren <newren@gmail.com>
- Date
- Jun 14, 2024, 17:41 UTC
- Message-ID
- <CABPp-BFvGa5KhoBs6n+mzka9LoHe3-Gx0JeAYjDQjaB=TyXGkg@mail.gmail.com>
- In-Reply-To
- <20240608104821.GF2659849@coredump.intra.peff.net>
On Sat, Jun 8, 2024 at 3:48 AM Jeff King <peff@peff.net> wrote:
Show 11 quoted lines
> > On Thu, Jun 06, 2024 at 06:19:21PM -0400, Taylor Blau wrote: > > > Looking at the remaining uses of mkstemp(), the remaining class of > > callers that don't use the tempfile.h API are for creating temporary > > .idx, .rev files, and similar. My personal feeling is that we should > > apply similar treatment there, since these files are generated based on > > .pack data, and thus keeping around temporary copies is unnecessary when > > they can be regenerated. > > And actual loose object and pack files themselves, I think.
[...]
Show 8 quoted lines
> So I'd argue that we should just treat object/pack tempfiles like the > rest, and delete them if they don't make it all the way to the rename > step. If we really want to support debugging, we could perhaps provide > a run-time knob to leave them in place (and maybe even have it apply to > _all_ tempfiles). > > But that is all way beyond your series, and I don't think there is any > urgent need to tackle it.
Regardless, it provides more context around the exact questions I had while reading the series. Everything in the series looked fine to me, but I wondered about packs and loose objects and why those are different. Anyway, I like your suggestions as a long term goal. (Perhaps handling packs and loose objects with tempfiles could serve as good microprojects?)