Comment by hinkley
2 days ago
When you do a shallow clone, no files would be present. However when doing a full clone you’ll get a full copy of each version of each blob, and what is being suggested is treat each revision as an rsync operation upon the last. And the more times you muck with a file, which can happen a lot both with assets and if you check in your deps to get exact snapshotting of code, that’s a lot of big file churn.
The overwhelming majority of large assets (images, audio, video) will receive near-zero benefit from using the rsync algorithm. The formats generally have massive byte-level differences even after small “tweaks” to a file.
Video might be strictly out of scope for git, consider that not even youtube allows 'updating' a video.
This will sound absolutely insane, but maybe the source code for the video should be a script? Then the process of building produces a video which is a release artifact?
> This will sound absolutely insane, but maybe the source code for the video should be a script? Then the process of building produces a video which is a release artifact?
It already kinda is, but that just means you now need access to all the raw footage, and rendering a video file in high quality & good compression takes a long time.
https://en.wikipedia.org/wiki/Edit_decision_list
This is relatively niche, but that's a thing for anime fan-encodes. Some groups publish their vapoursynth scripts, allow you to produce the same re-encoding (given you have the same source video). e.g.:
* https://github.com/LightArrowsEXE/Encoding-Projects
* https://github.com/Beatrice-Raws/encode-scripts
That is nowhere near practical for even basic use cases like a website or a mobile app.
A lot of video editing includes splicing/deleting some footage, rather than full video rework. rsync, with its rolling hash approach, can work wonders for this use-case.