Patch URL from pull requests should use full index to maintain stable contents

[zmughal]

The output of URLs with the .patch suffix should be similar to:

git show --full-index HEAD

otherwise tools that use the patches with a checksum of the contents can have different contents based on how much git decides to abbreviate the objects.

I have come across this here: microsoft/vcpkg#22681 (comment).

[dg0yt]

It seems like there is already an undocumented option: ?full_index=1
https://github.com/orgs/community/discussions/46034#discussioncomment-4846112

[fabian-thomas]

While adding ?full_index=1 helps, I still feel like this should be the default. Can someone comment on why it shouldn't?

[fabian-thomas]

On top, the compare endpoint doesn't even seem to support ?full_index=1, making more stable compare urls inherently unstable 😕

Example: https://github.com/NixOS/nixpkgs/compare/45fbef8fd5498614400dcb7fe602a26897f3dba4...e3d1f343b9bd07e245b440612bbc1018d14a3f71.patch?full_index=1
Observe how the commit hashes alternate in length when refreshing the page.

[fabian-thomas]

Note that this seems to only occur for big projects and on specific (probably busy) servers as already hinted at in the initial report. I suspect that github uses one checkout per repository (including forks) for performing operations like generating diffs and clears objects periodically. When one object then has the same n character hash by chance, git ommits a longer hash. If this assumption is true, this would be an even bigger argument for defaulting to full_index=1 as this potentially leaks metadata about other users.