git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Stability of git-archive, breaking (?) the Github universe, and a possible solution

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Feb 1, 2023, 23:16 UTC
Message-ID
<Y9ry5Wxck4s/X2B+@tapette.crustytoothpaste.net>
In-Reply-To
<230201.86pmatr9mj.gmgdl@evledraar.gmail.com>
On 2023-02-01 at 09:40:57, Ævar Arnfjörð Bjarmason wrote:
> "A spec" here seems like overkill to me, so far on that front we've been
> shelling out to gzip(1), and the breakage/event that triggered this
> thread is rectified by starting to do that again by default.
Sure, that will fix the immediate problem.
Show 9 quoted lines
> But so what? We don't need to make promises for all potential git
> implementations, just this one. So we could add a blurb like this to the
> docs:
> 
> 	As people have come to rely on the exact "deflate"
> 	implementation "git archive" promises to invoke the system's
> 	"gzip" binary by default, under the assumption that its output
> 	is stable. If that's no longer the case you'll need to complain
> 	to whoever maintains your local "gzip".

I don't think a blurb is necessary, but you're basically underscoring the problem, which is that nobody is willing to promise that compression is consistent, but yet people want to rely on that fact. I'm willing to write and implement a consistent tar spec and to guarantee compatibility with that, but the tension here is that people also want gzip to never change its byte format ever, which frankly seems unrealistic without explicit guarantees. Maybe the authors will agree to promise that, but it seems unlikely.

> If we wanted to be even more helpful we could bunde and ship an old
> version of GNU gzip with our sources, and either default to that, or
> offer it as a "--stable" implementation of deflate.

That would probably break things, because gzip is GPLv3, and we'd need to ship a much older GPLv2 gzip, which would probably differ from the current behaviour, and might also have some security problems.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Previous: Raymond E. PascoNext: Junio C Hamano
Message 44 of 57 in “Stability of git-archive, breaking (?) the Github universe, and a possible solution”
  1. Eli SchwartzJan 31, 2023
  2. Ævar Arnfjörð BjarmasonJan 31, 2023
  3. Eli SchwartzJan 31, 2023
  4. 0/9 git archive: use gzip again by default, document output stabiltyÆvar Arnfjörð Bjarmason, Feb 2, 2023
  5. 1/9 archive & tar config docs: de-duplicate configuration sectionÆvar Arnfjörð Bjarmason, Feb 2, 2023
  6. 2/9 git config docs: document "tar.<format>.{command,remote}"Ævar Arnfjörð Bjarmason, Feb 2, 2023
  7. 3/9 archiver API: make the "flags" in "struct archiver" an enumÆvar Arnfjörð Bjarmason, Feb 2, 2023
  8. 4/9 archive: omit the shell for built-in "command" filtersÆvar Arnfjörð Bjarmason, Feb 2, 2023
  9. 5/9 archive-tar.c: move internal gzip implementation to a functionÆvar Arnfjörð Bjarmason, Feb 2, 2023
  10. 6/9 archive: use "gzip -cn" for stability, not "git archive gzip"Ævar Arnfjörð Bjarmason, Feb 2, 2023
  11. 7/9 test-lib.sh: add a lazy GZIP prerequisiteÆvar Arnfjörð Bjarmason, Feb 2, 2023
  12. 8/9 archive tests: test for "gzip -cn" and "git archive gzip" stabilityÆvar Arnfjörð Bjarmason, Feb 2, 2023
  13. 9/9 git archive docs: document output non-stabilityÆvar Arnfjörð Bjarmason, Feb 2, 2023
  14. brian m. carlsonFeb 2, 2023
  15. Ævar Arnfjörð BjarmasonFeb 2, 2023
  16. Junio C HamanoFeb 2, 2023
  17. brian m. carlsonFeb 4, 2023
  18. Phillip WoodFeb 2, 2023
  19. Junio C HamanoFeb 2, 2023
  20. Raymond E. PascoFeb 2, 2023
  21. archive: document output stability concernsRaymond E. Pasco, Feb 3, 2023
  22. Ævar Arnfjörð BjarmasonFeb 3, 2023
  23. Phillip WoodFeb 6, 2023
  24. Theodore Ts'oFeb 3, 2023
  25. Junio C HamanoFeb 2, 2023
  26. René ScharfeFeb 4, 2023
  27. Ævar Arnfjörð BjarmasonFeb 5, 2023
  28. René ScharfeFeb 12, 2023
  29. brian m. carlsonJan 31, 2023
  30. Ævar Arnfjörð BjarmasonJan 31, 2023
  31. Konstantin RyabitsevJan 31, 2023
  32. brian m. carlsonJan 31, 2023
  33. Ævar Arnfjörð BjarmasonFeb 1, 2023
  34. demerphqFeb 1, 2023
  35. Michal SuchánekFeb 1, 2023
  36. demerphqFeb 1, 2023
  37. Ævar Arnfjörð BjarmasonFeb 1, 2023
  38. demerphqFeb 1, 2023
  39. Theodore Ts'oFeb 1, 2023
  40. Joey HessFeb 2, 2023
  41. Theodore Ts'oFeb 3, 2023
  42. Ævar Arnfjörð BjarmasonFeb 3, 2023
  43. Raymond E. PascoFeb 1, 2023
  44. brian m. carlsonFeb 1, 2023
  45. Junio C HamanoFeb 1, 2023
  46. brian m. carlsonFeb 2, 2023
  47. rsbecker@nexbridge.comFeb 2, 2023
  48. Ævar Arnfjörð BjarmasonFeb 3, 2023
  49. Ævar Arnfjörð BjarmasonFeb 2, 2023
  50. Eli SchwartzJan 31, 2023
  51. Konstantin RyabitsevJan 31, 2023
  52. Eli SchwartzJan 31, 2023
  53. Konstantin RyabitsevJan 31, 2023
  54. Michal SuchánekJan 31, 2023
  55. brian m. carlsonFeb 1, 2023
  56. Ævar Arnfjörð BjarmasonFeb 1, 2023
  57. brian m. carlsonFeb 1, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.