Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Git LFS can potentially break downstream clones #768

Open
mjcarroll opened this issue Dec 7, 2022 · 4 comments
Open

Git LFS can potentially break downstream clones #768

mjcarroll opened this issue Dec 7, 2022 · 4 comments

Comments

@mjcarroll
Copy link

Reported here: ros2/rosbag2#1199

Note that you could control the behavior with git environment variables as described here: #744 (comment), 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 (ros2/rosbag2#1200), but this would prevent you from using arbitrary commits.

@mjcarroll mjcarroll added the bug Something isn't working label Dec 7, 2022
@tfoote
Copy link

tfoote commented Dec 7, 2022

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
Copy link
Collaborator

I think pointing to tarballs of releases is a good idea for the mcap_vendor package in general, and have approved ros2/rosbag2#1200 - i'll also forward-port it to rolling 🔜. 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
Copy link

tfoote commented Dec 8, 2022

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.

@defunctzombie defunctzombie added bug Something isn't working and removed bug Something isn't working labels Dec 13, 2022
@foxhubber
Copy link

foxhubber bot commented Dec 13, 2022

Linear: FG-944

@james-rms james-rms removed the bug Something isn't working label Dec 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants