Hi Patrick, On Wed, 18 Dec 2024, Patrick Steinhardt wrote: > On Tue, Dec 17, 2024 at 12:33:10PM -0800, Junio C Hamano wrote: > > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > > writes: > > > > > This commit partially reverts 91839a88277 (ci: create script to set up > > > Git for Windows SDK, 2024-10-09). > > > > Thanks, will queue. > > Okay. Too bad that things regressed this badly with the change. I agree > that reverting is the right thing to do for now. I may revisit this > again in the next release cycle to investigate whether we can get it up > to par with the GitHub Actions. The way I implemented it should be eminently possible in PowerShell, too. Something like `Start-Process`, launching not an `Invoke-WebRequest` but instead `C:\Windows\system32\curl.exe` [*1*] to download the `.tar.gz` file (not the `.zip` file, more about that below). Another `Start-Process` should then be opened that executes `tar.exe` [*2*], and then the `stdout` of the former should be piped to the latter [*3*]. I do think that it makes a lot of sense to start extracting as soon as the first byte arrives instead of storing the archive as a temporary file and extracting it only once it has arrived completely. Now, why not use the `.zip` file instead of the `.tar.gz` file? In my analysis [*4*], I pointed out that the `.zip` file is about 10MB smaller, after all, and BSD tar (at least the version in `C:\Windows\system32`) is able to handle those, too, right? Not so fast. In my experiments, when streaming the `.zip` file to the `tar.exe -xf -` process, the `etc/` and `.sparse/` directories were consistently dropped. A bug, I guess. I ran out of time to investigate this in more depth. Since the artifacts are now hosted in a GitHub Release and updated regularly, and since those updates cannot be atomic (you can only upload a release asset if no asset of the same name exists already, read: the automation has to _delete_ that asset before uploading a new version), it would also be good to kind of expect that the file may be intermittently absent and add a back-off strategy [*5*]. > It would be great if the build infra was shared between our CIs, so I > think there's some value in it. But if the answer is "no" then I guess > that's ultimately fine, as well. It _could_ be done. But the advantages of having it versioned outside of the Git repository outweigh the benefits of that shared infrastructure, I believe. Ciao, Johannes Footnote *1*: https://github.com/git-for-windows/setup-git-for-windows-sdk/pull/965/commits/6db65223de699c4f75ab083f82f43947a53ad6ff#diff-6855ef61b94227f9264adab3ff9f2de95c2d7b4e451019cc0105896d32550eb0R58-R73 Footnote *2*: https://github.com/git-for-windows/setup-git-for-windows-sdk/pull/965/commits/6db65223de699c4f75ab083f82f43947a53ad6ff#diff-6855ef61b94227f9264adab3ff9f2de95c2d7b4e451019cc0105896d32550eb0R77-R86 Footnote *3*: https://github.com/git-for-windows/setup-git-for-windows-sdk/pull/965/commits/6db65223de699c4f75ab083f82f43947a53ad6ff#diff-6855ef61b94227f9264adab3ff9f2de95c2d7b4e451019cc0105896d32550eb0R88 Footnote *4*: https://github.com/git-for-windows/git-sdk-64/pull/87/commits/fdb0cea373893ce7d40bcfcfbeb7fd091a3c4020 Footnote *5*: https://github.com/git-for-windows/setup-git-for-windows-sdk/pull/965/commits/3d4ea07041d0740b21160a9d9a4181f569e706d8
