Live data from Hacker News

Git-Annex

git-annex.branchable.com

61–64 of 64 posts

Re: Git-Annex

#61

Git-Annex is a cool piece of technology, but my impression is that it works best for single-user repositories. So for instance, as @nolist_policy described in a sibling comment, managing all your personal files, documents, music, etc. across many different devices. I tried using it for syncing large files in a collaborative repository, and the use of "magic" branches didn't seem to scale well.

YMMV, but it works for my org. We're an archival institution and have been using git-annex for more than a decade as the storage backend for a digital repository system designed for long-term, robust preservation. Admittedly, we only have 15-20 staff; but +30TB of data, ~750K files (binaries + metadata), across hundreds of collection repos.

How (if you saw that need) did you address permissions concerns, e.g., around any Git users being able to force drop all files from a backend?

Back (long time ago) when I was looking into this, there was no KISS, out-of-the-box way to manage the Git Annex operations a Git user would be allowed to perform. Gitolite (or whatever Git platform of choice) can address access control concerns for regular Git pushes, but there is no way to define policies on Git Annex operations (configuration, storage management).

Might not be super hard to create a Gitolite plugin to address these, but ultimately for my use-case it wasn’t worth the effort (I didn’t really need shared Git Annex repos). Do you tackle these concerns somehow? I guess if people don’t interact with your repositories via Git/SSH but only through some custom UI, you might deal with it there.

Re: Git-Annex

#62
post #38

Earlier quoted context omitted.

How much data do you have? I'm using git-annex on my photos, and that are around 100k-1M files, several TB of data, on a ZFS. In the beginning, everything was fine, but it starts to become increasingly slow, such that every operation takes several minutes (5-30 mins or so). I wonder a bit whether that is ZFS, or git-annex, or maybe my disk, or sth else.

Why? WHY?! Why the heck are you using (D)VFS on your immutable data? What is the reasoning? That stuff is immutable and usually incremental.. Just throw proper syncing algoritm on it and sync w/ backups.. thats all. I wonder aby logic behind this... Docs and other files you often change is completly different story. This is where DVFS shines. I wrote my own very simple DVFS exacly for that case. You just create direc…

Why... not? Git just works for syncing data and version control and we're all familiar with it. It is also secure, reliable, available everywhere, decentralized, with built-in access control, deduplication, e2ee with gitcrypt... In short, it is great.

The problem is performance in some use cases, but I don't see anything fundamentally wrong with using git for sync.

Re: Git-Annex

#63
post #38

Earlier quoted context omitted.

Why? WHY?! Why the heck are you using (D)VFS on your immutable data? What is the reasoning? That stuff is immutable and usually incremental.. Just throw proper syncing algoritm on it and sync w/ backups.. thats all. I wonder aby logic behind this... Docs and other files you often change is completly different story. This is where DVFS shines. I wrote my own very simple DVFS exacly for that case. You just create direc…

Why... not? Git just works for syncing data and version control and we're all familiar with it. It is also secure, reliable, available everywhere, decentralized, with built-in access control, deduplication, e2ee with gitcrypt... In short, it is great. The problem is performance in some use cases, but I don't see anything fundamentally wrong with using git for sync.

Git wasnt designed for generic binary blob handling. Sure, if you repo is small and you set proper .gitattributes, it will work fine. But I would advise to use generic DVFS for such task.

Re: Git-Annex

#64
post #39
post #36

I've used this for years, but to me the big selling point was integration with cloud storage providers as a means of backup. That, however, was always flaky and dependent on unmaintained third-party plugins. I think there was also a bug at some point that caused some data inconsistencies, so eventually I stopped. Does anyone know if the situation has improved on that front in the past 5 years?

Depends on the cloud storage provider, I think. The best chances are with those that support the more standard protocols like S3, webdav, sftp, etc.. A relatively new development is the special remote built into rclone, which should be better maintained than some other third-party special remotes and provides access to all rclone-supported remotes.

Oh, really? rclone is great, but as a standalone thing it's really annoying to use. I didn't realize until now that it was missing a git-annex integration to be great. Thank you! I'll start using it again.
Post reply on HN