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
Jan 31, 2023, 22:32 UTC
Message-ID
<Y9mXB1LaYSUJBlwF@tapette.crustytoothpaste.net>
In-Reply-To
<20230131150555.ewiwsbczwep6ltbi@meerkat.local>
On 2023-01-31 at 15:05:55, Konstantin Ryabitsev wrote:
Show 21 quoted lines
> On Tue, Jan 31, 2023 at 09:54:58AM +0000, brian m. carlson wrote:
> > I'm one of the GitHub employees who chimed in there, and I'm also a Git
> > contributor in my own time (and I am speaking here only in my personal
> > capacity, since this is a personal address).  I made a change some years
> > back to the archive format to fix the permissions on pax headers when
> > extracted as files, and kernel.org was relying on that and broke.  Linus
> > yelled at me because of that.
> > 
> > Since then, I've been very opposed to us guaranteeing output format
> > consistency without explicitly doing so.  I had sent some patches before
> > that I don't think ever got picked up that documented this explicitly.
> > I very much don't want people to come to rely on our behaviour unless we
> > explicitly guarantee it.
> 
> I understand your position, but I also think it's one of those things that
> happen despite your best efforts to prevent it. :)
> 
> May I suggest adding a "git-archive --stable" that offers this guarantee,
> simply as a matter of codifying the fact that the world has built
> infrastructure around git's repeatable output. Maybe just for .tar (and
> .tar.gz).

It is my intention to implement just .tar. That's my proposal: simply a pax-based format that serializes in a consistent way according to a predefined spec.

As far as whether other people want to implement consistent compression, they are welcome to also write a spec and implement it. I personally feel that's too hard to get right and am not planning on working on it.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Previous: Konstantin RyabitsevNext: Ævar Arnfjörð Bjarmason
Message 32 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.