Recent comments posted to this site:
eh... i look elsewhere for a week and you design another line protocol! ;) so I guess it's too late to do anything to change this, but I wanted to share that similar efforts are being done over the backup software world, in particular in restic, which is working with the rclone project to implement an abstract get/pull mechanism to store blobs, a lot like what git-annex needs to be doing.
they wrote this using a binary protocol for speed (it's basically RPC at this point) and I encouraged them to at least use a standard one (they use protobufs + HTTP2 AKA gRPC, iirc, and it works over stdin/out). you might find the full thread interesting... it would be great if git-annex would support this natively instead of rolling its own protocol, because it would mean it could talk with other services like rclone or restic servers out of the box, without those endpoints having to implement yet another custom protocol.
but yeah, i'm way too late it seems. figured you might find it interesting anyways... congrats on the performance improvements!
Seems the git-annex-bin package is no longer in AUR.
@caleb any interesting in resurrecting the old git-annex-bin package?
It would be a welcome option for users that have no other haskell-based packages installed vs. the community/git-annex package that now depends on ghc and many separate haskell packages. Reply or ping me, I can assist.
If I have a big repo of YouTube stuff I might have some videos that I want to download with different options. Maybe I want higher quality for some videos, and don't care for others. It seems like youtube-dl-options can only be specified for an entire annex, though. I'd like to be able to do it per file.
The main motivation for this is YouTube videos where I only want the audio. Is there a good way to do this? Best I can think of is having a separate annex for audio and video.
Hi, from technical point of view, are there any drawbacks/limitations on adopting a workflow of everyone in the project using "git annex add" and relying on the annex.largefiles settings instead of them having to use the separate commands? * I would use repo v5 as repo v6 seems to still need work to do, and I don't need it's features. I just would like to avoid human error of people not using by mistake regular git add for bigfiles. I understand that repo v6 would allow, but I don't like it's default behavior of using unlocked mode when I add things with git add (although it would properly annex the files, but in unlocked mode these files would occupy space in the work copy, and I don't want that). Thanks.
@davi, you are using an ancient version of git-annex, from before this command was added. Upgrade.
I`m using version: 5.20151208 and there is no such command as git annex config. It is also not listed on git annex help
@elmimmo, you could add all those permutations, but there's no need to connect repositories that you don't need git-annex to transfer data between.
This is not a new protocol, it was added 2 years ago for git-annex's tor hidden service support.
git-annex already supports rclone via a special remote.
This protocol is only used when there's a git-annex repository on the other end, so I don't see any benefit in making it compatible with any other programs. And it has stuff in it that I'm sure if not in the protocol you talked about, like LOCKCONTENT.