Re: [jlreq] Bandwidth quota of Git LFS Data (#454)

> hrm,,, some thoughts...
> 
> 1. turning lfs files into normal one at HEAD only should be easy (just `git lfs untrack` and `git add`), but all lfs entries will remain (e.g. [github lfs document](https://docs.github.com/en/repositories/working-with-files/managing-large-files/removing-files-from-git-large-file-storage)). also removing and adding lfs files will break history incl. ones of PR. (we don't rely on commit hash, but just using PR ID, so changing history via force push will not be so harmful)

As far as I undersand, these files are only there for the record. They are not the ones that are actually used in the spec.
Plus, I'm not sure how it can break history.

> 3. I'm not sure something like `git lfs migrate export --include '*' --everything` could work or not.
> 4. looking at old discussion, it seems we just discussed about what way to take for binary files, but not considered / checked its file size against file size limit (50MB/100MB of github). so there is no reason we turn all lfs files into normal git files

AFAICS, the source images don't weight more than a few MB so we are still below the file size limit.

> 5. source archive could be one of bandwidth, but I am quite not sure why 75.32GB has been used against 0.54GB of actual total lfs file size. if bandwidth calculation is correct, it is around 140 times of total file size, so it could not be just a single archive download like just archive of HEAD, but quite multiple? If so, we should remove all history of lfs files from this repository.

The backup system runs at least daily so the process will take at least 15Gb/month. I mentioned the backup system but there might be other downloads from other sources.

> 6. I believe forks (like [my one](https://github.com/himorin/jlreq)) will consume storage and bandwidth from origin, and may need to ask something after we convert this repository??> > I don't think we want to check or use older source files in .ai or .indd than HEAD for future, since JL-TF is now finished all works on it and freezing (per new jlreq-d; errata could be fixed in future but marking not in scope for now). So removing every history of lfs tracked files via git rm as [@deniak](https://github.com/deniak) suggested and just adding the latest files into HEAD, could work.> 
> how about,,, let me try to find some time to how `git lfs migrate export --include '*' --everything` works and check its result?

I'm far from being a git LFS guru and it seems jlreq is the only repo relying on it but it's enough to exceed the bandwidth quota. Another option would be to disable backups for that repo but I don't think this is a good idea. My guess is that given the size of that repo, it's better to not rely on git LFS.

-- 
GitHub Notification of comment by deniak
Please view or discuss this issue at https://github.com/w3c/jlreq/issues/454#issuecomment-2654122519 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 February 2025 15:49:57 UTC