Recent comments posted to this site:
I followed the instruction to install git-annex on my Lenovo Vibe K4 running Android 6
At first I got the error /bin/sh/ is missing, which I worked around with termux-fix-shebang on runshell. Now I am getting this error.
proot info: vpid 1: terminated with signal 11
Please advice.
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. Especially since which options are available, or safe, could vary between versions of youtube-dl.
I have been trying to figure out how to use addurl to get this video. I have this in my mscourtstuff annex as a large binary, but I would really like to use the web as a remote for this.
Hughes v Hosemann 2010-CA-01949-SCT-43112001.mp4 youtube-dl --referer 'http://judicial.mc.edu/case.php?id=24206' http://player.vimeo.com/video/43112001
That's fabulous. A Bash alias around that command is really all I need when working in direct mode. (And the archive's too damn big to switch back and forth between direct/indirect.)
I was just too much a newb with git attributes to know it could be done that way. For discoverability, maybe that command could be placed in an "examples" section in the primary documentation above?
@rrnewton I know people do commonly accomplish this
by something like git -c annex.largefiles='exclude(*)' annex add
A shorter way to write that would only be useful for direct mode, so I'm inclined not to add it, but open a todo item if you want to discuss that.
When in direct mode, the "add the non-large file directly to the git repository" behavior described above is very useful, because the option of typing simply git add foo, does not exist as it does in indirect mode.
However, I can't see any combination of flags that trigger this behavior. I suppose it can be accomplished by temporarily setting annex.largefiles to a huge value before executing git annex add (i.e. creating a .gitattributes and then deleting it). I think I'll try that as a work-around, but it would be great to have a flag that accomplishes this.
is there some combination of this and the gcrypt special remote that would give me the following properties:
- password-less operation (ie. allow uploading content without the private key)
- easy revocation and key rotation (ie. not encrypt directly with GnuPG but instead encrypt a keyfile with the public keys)
It seems to me this would be technically possible, no? A mix of "hybrid" and "sharedpubkey", basically...?
Hybrid works great, except I can't use it in my scenario because I am trying to automate backups and it will prompt me for the private key password. I guess the solution here is to have a special unencrypted private key for the batch job? Thanks! -- [[anarcat]