{"thread":{"id":"65987","subject":"[PATCH 0/2] packfile URIs: support concurrent downloads","startedAt":"2026-07-13T22:34:26Z","lastAt":"2026-07-14T07:31:39Z","messageCount":5,"participants":["Ted Nyman","Junio C Hamano","Taylor Blau","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"548045","messageId":"alVn7UWvdWRAG-Vv@com-76773","threadId":"65987","inReplyTo":null,"subject":"[PATCH 0/2] packfile URIs: support concurrent downloads","fromName":"Ted Nyman","fromEmail":"tnyman@openai.com","sentAt":"2026-07-13T22:34:21Z","receivedAt":"2026-07-13T22:34:26Z","isPatch":true,"body":"Packfile URI downloads currently stage a pack at\nobjects/pack/pack-.pack.temp. Two Git processes fetching the same\npack into one object database can append to that file concurrently,\nwhich can corrupt the temporary pack or cause a resume request at EOF.\n\nThe first patch gives each direct packfile URI download a private\ntemporary file. Ordinary dumb HTTP pack requests retain their existing\nresumable staging behavior. A later packfile URI retry starts a new\ndownload.\n\nThe second patch handles the related .keep race. When another process\nhas already created the keep file, index-pack reports \"pack\"\ninstead of \"keep\". Accept both successful forms and remove\nonly keep files created by the current process.\n\nEach patch adds a regression test for its respective race.\n\nTed Nyman (2):\n http: use unique tempfiles for packfile URI downloads\n fetch-pack: accept \"pack\" output for packfile URIs\n\n Documentation/git-http-fetch.adoc | 5 +-\n fetch-pack.c | 36 ++++++++-------\n http.c | 77 +++++++++++++++++++++----------\n http.h | 1 +\n t/t5550-http-fetch-dumb.sh | 72 ++++++++++++++++++++++++++++-\n t/t5702-protocol-v2.sh | 31 +++++++++++++\n 6 files changed, 177 insertions(+), 45 deletions(-)\n\n\nbase-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc\n-- \n2.55.0\n"},{"id":"548050","messageId":"xmqq4ii2wlo1.fsf@gitster.g","threadId":"65987","inReplyTo":"alVn7UWvdWRAG-Vv@com-76773","subject":"Re: [PATCH 0/2] packfile URIs: support concurrent downloads","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-13T22:48:46Z","receivedAt":"2026-07-13T22:48:49Z","isPatch":true,"body":"Ted Nyman writes:\n\n> Packfile URI downloads currently stage a pack at\n> objects/pack/pack-.pack.temp. Two Git processes fetching the same\n> pack into one object database can append to that file concurrently,\n> which can corrupt the temporary pack or cause a resume request at EOF.\n>\n> The first patch gives each direct packfile URI download a private\n> temporary file. Ordinary dumb HTTP pack requests retain their existing\n> resumable staging behavior. A later packfile URI retry starts a new\n> download.\n>\n> The second patch handles the related .keep race. When another process\n> has already created the keep file, index-pack reports \"pack\"\n> instead of \"keep\". Accept both successful forms and remove\n> only keep files created by the current process.\n>\n> Each patch adds a regression test for its respective race.\n>\n> Ted Nyman (2):\n> http: use unique tempfiles for packfile URI downloads\n> fetch-pack: accept \"pack\" output for packfile URIs\n\nThis cover letter has\n\n Message-ID: \n\nbut in the header of [PATCH 1/2] has\n\n Message-ID: \n References: \n In-Reply-To: \n\nSimilarly, [PATCH 2/2] has\n\n Message-ID: \n References: \n In-Reply-To: \n\nAnd \"b4 am\" seems to be having problem grabbing the patchset X-<.\n\n"},{"id":"548051","messageId":"alVs4JO9BNQrXsnO@com-76773","threadId":"65987","inReplyTo":"xmqq4ii2wlo1.fsf@gitster.g","subject":"Re: [PATCH 0/2] packfile URIs: support concurrent downloads","fromName":"Ted Nyman","fromEmail":"tnyman@openai.com","sentAt":"2026-07-13T22:55:28Z","receivedAt":"2026-07-13T22:55:33Z","isPatch":true,"body":"> And \"b4 am\" seems to be having problem grabbing the patchset X-<.\n\nSorry for the noise -- Mutt rewrote the original cover-letter\nMessage-ID. The patches reference the corrected cover:\n\n https://lore.kernel.org/git/cover.1783982021.git.tnyman@openai.com/\n\nI confirmed that this retrieves both patches:\n\n b4 am cover.1783982021.git.tnyman@openai.com\n\nThanks,\nTed\n"},{"id":"548054","messageId":"alWiEXbP5vOcCJ7F@com-79390","threadId":"65987","inReplyTo":"alVs4JO9BNQrXsnO@com-76773","subject":"Re: [PATCH 0/2] packfile URIs: support concurrent downloads","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-07-14T02:42:25Z","receivedAt":"2026-07-14T02:42:32Z","isPatch":true,"body":"On Mon, Jul 13, 2026 at 03:55:28PM -0700, Ted Nyman wrote:\n> > And \"b4 am\" seems to be having problem grabbing the patchset X-<.\n>\n> Sorry for the noise -- Mutt rewrote the original cover-letter\n> Message-ID. The patches reference the corrected cover:\n>\n> https://lore.kernel.org/git/cover.1783982021.git.tnyman@openai.com/\n>\n> I confirmed that this retrieves both patches:\n>\n> b4 am cover.1783982021.git.tnyman@openai.com\n\nThis is a mistake on my end as I was porting over some of the scripts\nfor sending patches to the mailing list to OpenAI's infrastructure.\n\nThe short version of this e-mail is that the issue is fixed. But the\nlonger version is funny (at least to me), so I figured I would share.\n\nAs some background, my workflow for sending patches to the mailing list\nis to use a script called 'git mail' that effectively runs format-patch\nto build an *.mbox and then opens Mutt in that directory. I then review\nthe patches one last time before sending, and then run a macro I have\nbound to 'B', which (effectively) runs .\n\nFor reasons that I cannot quite recall, I chose this workflow many years\nago when it would likely have been more appropriate to use `mutt -H`,\nwhich does *not* rewrite Message-ID headers when resending.\n\nTo work around this, I wrote a patch that I applied to the version of\nMutt I used both on my old work laptop as well as the Linux workstation\nwhere I did the majority of my work. The patch is fairly small, and is\neffectively:\n\n--- 8< ---\ndiff --git a/postpone.c b/postpone.c\nindex f557976d..accbb4f6 100644\n--- a/postpone.c\n+++ b/postpone.c\n@@ -607,13 +607,9 @@ int mutt_prepare_template (FILE *fp, CONTEXT *ctx, HEADER *newhdr, HEADER *hdr,\n newhdr->content->length = hdr->content->length;\n mutt_parse_part (fp, newhdr->content);\n\n- /* If resending a message, don't keep message_id or mail_followup_to.\n- * Otherwise, we are resuming a postponed message, and want to keep those\n- * headers if they exist.\n- */\n+ /* If resending a message, don't keep mail_followup_to. */\n if (resend)\n {\n- FREE (&newhdr->env->message_id);\n FREE (&newhdr->env->mail_followup_to);\n }\n\n--\n2.26.0.106.g9fadedd637\n--- >8 ---\n\n(The Git version this patch was prepared with should give you some sense\nof how ancient this part of my workflow is ;-).)\n\nWhen looking at this yesterday after sending the 'no-ref-delta' patches\nto the list, I could not figure out quite why my Mutt client was\nrewriting Message-ID headers until I remembered the aforementioned\npatch.\n\nThe fix is somewhat OpenAI-specific, and so not interesting to share\nwith the list, but effectively relies on piping messages to 'mutt -H -'\nto send the message without dropping (and thus rewriting) the Message-ID\nheader.\n\n(As an alternative, I could have continued to carry that patch to\n'postpone.c', but in retrospect it seems gross^W unnecessary, so I\nditched it.)\n\nThanks,\nTaylor\n"},{"id":"548088","messageId":"20260714073137.GC4058320@coredump.intra.peff.net","threadId":"65987","inReplyTo":"alWiEXbP5vOcCJ7F@com-79390","subject":"Re: [PATCH 0/2] packfile URIs: support concurrent downloads","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-07-14T07:31:37Z","receivedAt":"2026-07-14T07:31:39Z","isPatch":true,"body":"On Mon, Jul 13, 2026 at 07:42:25PM -0700, Taylor Blau wrote:\n\n> As some background, my workflow for sending patches to the mailing list\n> is to use a script called 'git mail' that effectively runs format-patch\n> to build an *.mbox and then opens Mutt in that directory. I then review\n> the patches one last time before sending, and then run a macro I have\n> bound to 'B', which (effectively) runs .\n> \n> For reasons that I cannot quite recall, I chose this workflow many years\n> ago when it would likely have been more appropriate to use `mutt -H`,\n> which does *not* rewrite Message-ID headers when resending.\n\nYou might have inherited the thing from me. I thought I\nused it exactly because \"-H\" insisted on rewriting the message-id, but\nit doesn't seem to now. So either I've completely forgotten the reason,\nor perhaps the behavior used to be different.\n\nI also like that lets me open the whole mbox and send\neach message within a single session. But I never run into the issue\nyou're mentioning because I write my cover letter separately as a normal\nemail, and then generate the actual patches as in-reply-to (with some\nscript magic to pull the message-id from my sent folder).\n\nSo possibly my fault for leading you in the wrong direction many years\nago, or your fault for not following my sage advice to the letter. ;)\n\n-Peff\n"}]}