nightlark wrote: Oh, I get it. This change looks like it's okay and shouldn't have side effects that would break other things, and would address issues if the upstream projects are downloading GitHub's automatically generated archives for specific commits. I am curious though why the downstream projects are referencing commits that don't correspond to a release tag, since commits corresponding to release tags just use the tag as the `describe-name` and won't change over time. Like the download for commit corresponding to the llvmorg-23.1.1 tag (`https://github.com/llvm/llvm-project/archive/6dfe1677ab8dffbc6ec13d53a1e0215d75147689.zip`) just has this in the `.git_archival.txt` file:
``` node: 6dfe1677ab8dffbc6ec13d53a1e0215d75147689 node-date: 2026-09-07T13:01:29Z describe-name: llvmorg-23.1.1 ``` Aside from not quite getting why commits that weren't tagged for a particular release being used, essentially the issue is that GitHub generates these archives "on demand", and the git commit hash abbreviation gets shortened based on how many commits are in a repository in order to avoid collisions. So using `https://github.com/llvm/llvm-project/archive/57186afd172250f0c1695b809505947382f227cd.zip` as an example, hypothetically when the repository has 1 commit, maybe the first two bytes of the commit hash is enough to uniquely describe the commit with minimal chances of hash collisions and `.git_archival.txt` will look like this: ``` node: 57186afd172250f0c1695b809505947382f227cd node-date: 2026-09-15T11:25:00-07:00 describe-name: llvmorg-24-init-9001-g5718 ``` But then a year later after several hundred more commits are added the odds of a collision between abbreviated commits has now increased, so the downloaded archive file will now have a describe-name with a longer abbreviated hash to ensure the abbreviation still uniquely describes the commit, perhaps with the `.git_archival.txt` file now looks like this: ``` node: 57186afd172250f0c1695b809505947382f227cd node-date: 2026-09-15T11:25:00-07:00 describe-name: llvmorg-24-init-9001-g57186afd17225 ``` And because the `.git_archival.txt` file contents changed, the overall hash of the downloaded source archive will also no longer match, potentially causing issues if a downstream consumer expects the contents to always remain the same. For what it's worth, GitHub doesn't make any immutability guarantees for the on-demand archive downloads; so while we can try to keep the contents from changing by making this change, there is no guarantee that something outside of our control could alter the hashes -- so downstream consumers of those archives should probably keep that in mind when using those archives instead of an uploaded release asset such as `llvm-project-23.1.1.src.tar.xz`. (@akuegel might be worth checking if OpenXLA/Bazel actually want to be using the on-demand github source archives rather than the uploaded release asset). https://github.com/llvm/llvm-project/pull/223362 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
