Recent comments posted to this site:
@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]
Setting all the environment variables from inside still did not break the tar execution; last resort was disabling proot in runshell. I still had to keep the termux-fix-shebang workaround.
$ ./git-annex.linux/runshell
$ mkdir test; cd test
$ git init
$ git annex init
From a first glance, things appear to be working now. I had to run termux-fix-shebang on the .git/hooks/*
and set TMPDIR=something-that-actually-exists, but short of that, local adding and committing as well as moving data around.
Joey, you mentioned ghc runtime issues when introducing proot. Anything particular I should test?
I'm experiencing the same issue as CandyAngel on an arm64 tablet (which should be able to execute regular arm code).
Tracing down from the error message:
$ ./git-annex.linux/runshell
proot error: execve("/data/data/com.termux/files/home/git-annex.linux/bin/sh"): No such file or directory
[...]
$ head -n1 /data/data/com.termux/files/home/git-annex.linux/bin/sh
#!/bin/sh
$ which sh
/data/data/com.termux/files/usr/bin/sh
So it might just be that the different environments disagree which sh is now executable. For contrast, trying a bash (which is not in /bin/):
$ ./git-annex.linux/runshell bash
bash-4.4$ git-annex
bash: /data/data/com.termux/files/home/git-annex.linux/bin/git-annex: /bin/sh: bad interpreter: No such file or directory
Ok, /bin/sh is obviously bad influence here.
$ termux-fix-shebang git-annex.linux/bin/*
$ ./git-annex.linux/runshell bash
bash-4.4$ git-annex
Segmentation fault
At first glance this does sound like "Mh, we can't execute 32bit binaries her", but look:
bash-4.4$ ./git-annex.linux/lib/ld-linux.so.3 # that's what exe/sh is symliked to
Segmentation fault
$ exit # now we're out of the runshell again
$ /git-annex.linux/lib/ld-linux.so.3
Usage: ld.so [OPTION]... EXECUTABLE-FILE [...]
Something in the environment is breaking things. My current stage of drilling is that I can run the variables-expanded version of [[!toggle text=tar id=tarcommand]] [[!toggleable id=tarcommand """
GIT_ANNEX_PROGRAMPATH=tar ./git-annex.linux/exe/tar --library-path /data/data/com.termux/files/home/git-annex.linux//usr/lib/arm-linux-gnueabi/gconv:/data/data/com.termux/files/home/git-annex.linux//usr/lib/arm-linux-gnueabi/audit:/data/data/com.termux/files/home/git-annex.linux//etc/ld.so.conf.d:/data/data/com.termux/files/home/git-annex.linux//lib:/data/data/com.termux/files/home/git-annex.linux//lib/arm-linux-gnueabi:/data/data/com.termux/files/home/git-annex.linux//usr/lib/arm-linux-gnueabi: ./git-annex.linux/shimmed/tar/tar --help
"""]] successfully from the outside but not from within runshell. Will update when I've found more.
@CandyAngel git-annex.linux/bin/sh is included in the bundle. If proot cannot run it, it seems likely that you have downloaded a build of git-annex that does not match the CPU architecure of your Android device. While most Android devices are arm, some use intel or mips..
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?