Hacker News Reader

Comment by metaphor | Hacker News Reader

> 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??

View on HN

you can copy/move/clone the local repo you already have. no need to clone from remote just to switch to a different machine.

To 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.

i 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.

Reply on news.ycombinator.com