Recent comments posted to this site:
@hobbes, there's not currently a way to do per-file youtube-dl options.
The difficulty is that we don't know what youtube-dl options might be
unsafe, and which such a feature could make eg git annex get
use when run
by a different user.
I feel that this needs some support in youtube-dl to avoid git-annex needing to know about all its safe options.
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.
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.
On macOS High Sierra (10.13.3) trying to use git-annex from the latest .dmg shows the following error:
I ran it by opening the .app directory (Show Package Contents) and running the
runshell
script to set up the environment: