Recent comments posted to this site:

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?

Comment by rrnewton Mon May 21 18:09:35 2018

@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.

Comment by joey Mon May 21 16:36:51 2018

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.

Comment by rrnewton Mon May 21 05:29:06 2018
My apologies. I will do that in future. I've removed my comments.Hopefully that doesn't cause more confusion. It's working great now. Thanks for the amazing software!
Comment by allforabit Sat May 19 23:48:05 2018

is there some combination of this and the gcrypt special remote that would give me the following properties:

  1. password-less operation (ie. allow uploading content without the private key)
  2. 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]

Comment by anarcat Thu May 17 21:02:32 2018
Probably should have given some platform details to my findings that proot is counter-productive on my device: I'm running LineageOS 14.1-20180206-NIGHTLY-gts210vewifi (LineageOS API level 7, Android 7.1.2, Kernel 3.10.102) on a Samsung SM-T813 (arm64).
Comment by https://christian.amsuess.com/chrysn Tue May 15 20:29:57 2018

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?

Comment by https://christian.amsuess.com/chrysn Tue May 15 19:57:34 2018

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.

Comment by https://christian.amsuess.com/chrysn Tue May 15 19:19:38 2018
My phone is an ARMv7, according to /proc/cpuinfo in Termux, so armel would be the correct package? That is the one I have installed..
Comment by CandyAngel Tue May 15 16:15:32 2018

@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..

Comment by joey Tue May 15 15:54:54 2018