Recent comments posted to this site:
The correct old hash value for the empty file SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is pX/ZJ .
The text describes the old hash value computation incorrectly, because it doesn't mention that 1 bit is skipped between each group of 5 bits. See the sample implementation in display_32bits_as_dir in https://github.com/joeyh/git-annex/blob/master/Locations.hs
TODO: stream the file up/down the pipe, rather than using a temp file
You might want to use chunked transfer, i.e. a series of "EXPECT 65536" followed by that many bytes of binary data and an EOF marker (EXPECT-END or EXPECT 0), instead of escaping three characters (newline, NUL, and the escape prefix) and the additional unnecessary tedious per-character processing that would require.
Is there a low cost web hosting solution that would support a public git-annex repo relatively simply with simple access to download the public files.
I figure I could set up an Amazon EC2 micro instance and mount an s3 share, hosting the git-annex remote, but this is a lot of overhead for something that dropbox does with 1 click "share dropbox link"?
Any suggestions would be great!
Adding:
'git-annex-shell' =>1,
To the .gitolite.rc file resulted in the "FATAL: suspicous characters loitering about 'git-annex-shell 'configlist' '/~/testing''...
Gitolite source code (https://github.com/sitaramc/gitolite/commit/b1d3c0571409b7c6279fc6a77253c3bc262ab425#diff-79a3701e9e2cee0ea1316451c21a3fec) requires this entry:
'git-annex-shell ua'
Just to support Nigel's comment; it's good to be precise and clear about what happens to the files from the start. I've sent a similar suggestion to the mailing list.