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

Re: [PATCH 9/9] git archive docs: document output non-stability

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 2, 2023, 16:34 UTC
Message-ID
<xmqq1qn8vxej.fsf@gitster.g>
In-Reply-To
<Y9uPhPnNFlCju8Fo@tapette.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 16 quoted lines
>> +* We will do our best not to change the "tar" output itself, but won't
>> +  promise that we're never going to change it.
>> ++
>> +If you must avoid using "git" itself for the tree validation, you
>> +should be checksumming the uncompressed "tar" output, not e.g. the
>> +compressed "tgz" output.
>> ++
>
> I don't think I want to state this, because it implies that the changes
> I made that broke kernel.org (making tar.umask apply to pax headers)
> wouldn't have been allowed.  We should probably just state that "we
> won't promise that the tar output won't change between versions". Maybe,
> "We won't change the tar output needlessly, but it may change from time
> to time."  That is, we won't be "let's change the format just to mix it
> up for users", but if there's a valuable patch that could be applied,
> then we might well take it.

I agree with you. Giving "will do our best not to" is still too strong for that. We won't change the format willy-nilly but when there is a good reason to do so, we should be able to fix or improve the output.

Show 8 quoted lines
>> +While you shouldn't assume that different versions of git will emit
>> +the same output, you can assume (e.g. for the purposes of caching)
>> +that a given version's output is stable.
>
> Unfortunately, this isn't actually true if someone uses export-subst.
> That's because adding unrelated objects can increase the length of
> abbreviations, and then the tar contents can be different.  I've
> actually seen this in the wild.

"subst" is certainly an issue, especially when the substitution is unstable.

There shouldn't be cross platform differences to break bit-for-bit stability at least for "tar" format, as we do not rely on any external library. Can we say the same for "zip"? I thought we throw the blob at git_deflate_*() so the exact bitstream is up to the libz implementation?

Previous: Ævar Arnfjörð BjarmasonNext: brian m. carlson
Message 16 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.