Git LFS can potentially break downstream clones

[mjcarroll]

Reported here: https://github.com/ros2/rosbag2/issues/1199

Note that you could control the behavior with git environment variables as described here: https://github.com/foxglove/mcap/pull/744#issue-1458994216, but there isn't a particularly convenient mechanism for passing those into the fetchcontent functionality in cmake.

As a workaround, the tagged tarballs are an option (https://github.com/ros2/rosbag2/pull/1200), but this would prevent you from using arbitrary commits.

[tfoote]

Note that this will also potentially break anyone else who wants to download the source code from git. And will limit community downloads to a quota'd amount which we've run into major issues with projects that become popular and are cutoff.

[james-rms]

I think pointing to tarballs of releases is a good idea for the mcap_vendor package in general, and have approved https://github.com/ros2/rosbag2/pull/1200 - i'll also forward-port it to rolling :soon:. Developers can temporarily use GIT / GIT_TAG in development branches if they need to point to an unreleased branch.

@tfoote are you able to link to a github issue or some background relating to community download of popular projects being quota'd?

I also wonder if it's possible to configure LFS to not pull on initial clone via .lfsconfig or .gitconfig - I may spend some time on this this week.

[tfoote]

The quota includes public repos and is per account/organization.

https://docs.github.com/en/billing/managing-billing-for-git-large-file-storage/viewing-your-git-large-file-storage-usage

"Bandwidth and storage usage only count against the repository owner's quotas. In forks, bandwidth and storage usage count against the root of the repository network. Anyone with write access to a repository can push files to Git LFS without affecting their personal bandwidth and storage quotas or purchasing data packs. Forking and pulling a repository counts against the parent repository's bandwidth limit. Unused bandwidth doesn't roll over month-to-month."

I don't think that we have a public ticket about it. It was a test repository that we were trying out for a project. We added a medium sized files ~50MB. With the default 2GB quota that means only 40 clones. So when we spun up CI for it and a few developers started working on the project we ran out of quota within the week. So we started over on a new repo. If you decided that you want to pay for the quota for the community, one 50MB file and the current $5/50GB https://docs.github.com/en/billing/managing-billing-for-git-large-file-storage/about-billing-for-git-large-file-storage that's about 0.5 cents per clone which if you get a popular project can add up quite quickly.

[foxhubber[bot]]

Linear: FG-944

[jtbandes]

Seems like the rosbag2 issue was resolved and we don't have further plans to change anything about the repo structure at this time. If this continues to be an issue in the future, we could reopen/revisit.