3 ms·
> With seven rooms photographed so far, my repo right now is 53 GB, since I'm storing all of the photos that go into each focus-stack, as well as the raw (xcf)
by metaphor 2y ago
> With seven rooms photographed so far, my repo right now is 53 GB, since I'm storing all of the photos that go into each focus-stack, as well as the raw (xcf) versions of each shot so that I can edit and color-correct without repeated JPEG compression.
I wonder how the author manages this bloat if he has to pivot to a different workstation. LFS enabled in his GitLab instance? Shallow clone? Just swallow whole??
- em-bee 2y agoyou can copy/move/clone the local repo you already have. no need to clone from remote just to switch to a different machine.
- metaphor 2y agoTo clarify, assume in good faith that pivot in context means compelled towards involuntary action---i.e. unexpected loss of local data, as opposed to a matter of routine shift in workflow---where the remote forge is being tapped for its secondary function as off-site backup. The question was more intended to probe remote UX resilience near the limits of pain when faced with massive git repos which primarily capture binary assets/artifacts.
- em-bee 2y agoi find that interpretation a bit of a stretch. you could have expressed that more clearly. especially given that the obvious solution is to have local backups. what else could you do? i have been discussing this on HN before in the context of a multi TB archive of photos and videos (part of which happened to be for a film project, so similar considerations apply). raid, external disk, and remote copy. for the film footage, everyone working with it has a full copy too, even if they don't need all of it. just in case. if you need to work with the data there is pretty much no other option.