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]