undefined | Better HN

0 pointsicebraining8y ago0 comments

Git-annex doesn't look for files in random places. It uses the regular git remotes, plus something it calls "special remotes" which are basically accounts on file servers/S3/etc that you can manually add.

If Github et all thought this was confusing, they could have made a "beginner's mode" that auto-selected the storage server based on the git server, like LFS does. Which would still have been better, since it wouldn't have required a custom server API.

It was very hard to use in asymmetric cases where different people have different credentials

Right, but LFS can't be used in asymmetric cases at all - it assumes anyone with access to the git repository has access to the LFS storage area.

0 comments

rspeer8y ago

> Right, but LFS can't be used in asymmetric cases at all - it assumes anyone with access to the git repository has access to the LFS storage area.

Wait, really? I thought that Git LFS let people with push access push files to the LFS area, which can then be read by anyone. That's asymmetric in the way everyone expects from GitHub. But I didn't use Git LFS because it's too expensive.

Yes, I probably encountered extra weirdness from git-annex, from the fact that the codebase was on GitHub, which doesn't support git-annex, so _everything_ in git-annex had to be on a different remote.

If it was meant to be used with the upstream as the only remote, that makes things make a lot of sense, and explains why my attempt to use it felt a lot like early Git, where there was no good upstream service like GitHub.

j / k navigate · click thread line to collapse

0 comments

rspeer8y ago

> Right, but LFS can't be used in asymmetric cases at all - it assumes anyone with access to the git repository has access to the LFS storage area.

j / k navigate · click thread line to collapse