mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2013-10-28 11:24:59 -04:00
commit f697c41e62
6 changed files with 110 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/bugs/directory_remote_+_shared_encryption_+_chunk_size___61___lost_files__63__/comment_2_8d09cc0e06548c4ebde7956edd1b5d85._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://jspk.clavid.com/"
nickname="flabbergast"
subject="comment 2"
date="2013-10-28T09:36:19Z"
content="""
Thanks! I've checked now and the problem is gone.
"""]]

14
doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.47"
subject="comment 1"
date="2013-10-27T21:19:45Z"
content="""
When you create an encrypted rsync repository using the webapp like that, its encryption key is stored in your git repository, using the [[shared encryption scheme|encryption#index2h2]]. No gpg key needs to be used to decrypt files from the rsync repository; anyone with a clone of your git repository can do so. This has its plusses and its minuses; the webapp picks that type of encryption because it's easy to use.
So, the answer is to just make a clone of your repository on the other machine, and then you can use it. There are lots of ways to do that; if you stay in the webapp, go to Add Another Repisitory and any of the \"Share with your other devices\", \"Share with a friend\", or \"Local computer\" options are easy ways to do it.
----
Now, if you had, manually, set up a rsync repository encrypted with the [[hybrid encryption key scheme|encryption#index1h2]], to access it from another computer with clone of the repository you would need to have a gpg key that has been given access to the repository. So you would either copy your gpg secret key to the other computer, or if you don't want to trust that other computer with the your main gpg key, you could make another gpg secret key for that computer, and add that key as one of the keys that can access the encrypted repository. (Or, if the computer belonged to a friend, you could just get their gpg key, and add it.)
"""]]

14
doc/forum/known_and_local_annex_keys.mdwn Normal file
View file

@ -0,0 +1,14 @@
I have a direct repository with the assistant running (v4.20131002). The repo is in the backup group and should be grabbing every known annex file. Yet `git annex status` says:
local annex keys: 1386
local annex size: 94.53 gigabytes
known annex keys: 1387
known annex size: 94.53 gigabytes
As you can seem there is one more known annex key than there are local ones. Neither `git annex get` nor `git annex sync` changes the numbers. According to `tree` the repo dir contains exactly 1387 files, which means that the missing file must exist on disk.
1) How do I find out which is the file in question? How do I get it synchronized?
Yesterday there were 1376 known annex keys. Today there are 1387. For some reason the number of keys went up by 11, and I would like to know how and why. The log suggests that a couple of files have been added from inside the repo directory, but I am positive that these files already existed in the annex directory yesterday, and that I ran `git annex sync` manually without the number of local and/or known keys going up.
2) Why weren't the files synced before? Is there a way to find out whether they were or were not part of the annex yesterday - maybe list all files sorted by the date they were added?

41
doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment Normal file
View file

@ -0,0 +1,41 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI"
nickname="Michele"
subject="still cannot push when remote has renames"
date="2013-10-27T23:06:03Z"
content="""
now, I went again through docs, and i realized how stupid was issuing a git pull on a direct repo. thanks for your patience.
but, i double checked the configuration, I assume \"receive.denyNonFastForwards\" is false by default, but anyway I set it up explicitely so that now my git config (on the linux indirect repo - with respect to my previous example, I got rid of the \"extra\" bare repo in the middle) shows:
$ git config --list
user.email=m@g.com
user.name=michele
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
annex.uuid=d084e0fd-95a7-4c98-a206-fbf2c85b779d
annex.version=3
receive.denynonfastforwards=false
still I am receiving the push refusal:
M:\win>git annex sync
commit
ok
pull origin
ok
push origin
To ssh://michele@home/home/michele/casa
! [rejected] master -> synced/master (non-fast-forward)
error: failed to push some refs to 'ssh://michele@home/home/michele/casa'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and merge the remote changes
hint: (e.g. 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
failed
git-annex: sync: 1 failed
Same happens with a bare repository in the middle. BTW: the windows \"client\" repository is behind NAT, so that the linux indirect doesn't actively sync against it: could that be source of the problem ?
"""]]

30
doc/todo/Build_for_Synology_DSM/comment_15_9525cd0d75ff4c15182d10a855774b69._comment Normal file
View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="lorenzo"
ip="84.75.27.69"
subject="Running Debian squeeze binaries on libc 2.5 based NAS"
date="2013-10-27T23:56:26Z"
content="""
Following the suggestions in this page I tried to run the binaries that debian provides on my Lacie NetworkSpace which is another one of these NAS devices with old libc. After uploading the binaries and required libraries and using `LD_LIBRARY_PATH` to force the loader to use the version I uploaded of the libraries I was still having a segfault (similar to what Franck was experiencing) while running git-annex in a chroot was working.
It turns out that it is possible to solve the problem without having to use chroot by not loading the binary directly but by substituting it with a script that calls the correct `ld-linux.so.3`. Assume you have uncompressed the files from the deb packages in `/opt/git-annex`.
First create a directory `/opt/git-annex/usr/bin/git-annex.exec` and copy the executable `/opt/git-annex/usr/bin/git-annex` there.
Then create script `/opt/git-annex/usr/bin/git-annex` with the following contents:
#!/bin/bash
PREFIX=/opt/git-annex
export GCONV_PATH=$PREFIX/usr/lib/gconv
exec $PREFIX/lib/ld-linux.so.3 --library-path $PREFIX/lib/:$PREFIX/usr/lib/ $PREFIX/usr/bin/git-annex.exec/git-annex \"$@\"
The `GCONV_PATH` setting is important to prevent the app from failing with the message:
git-annex.exec: mkTextEncoding: invalid argument (Invalid argument)
The original executable is moved to a different directory instead of being simply renamed to make sure that `$0` is correct when the executable starts. The parameter for the linker `--library-path` is used instead of the environment variable `LD_LIBRARY_PATH` to make sure that the programs exec'ed by git-annex do not have the variable set.
Some more info about the approach: [[http://www.novell.com/coolsolutions/feature/11775.html]]
"""]]

3
doc/todo/whishlist:_git_annex_drop_--dry-run.mdwn Normal file
View file

@ -0,0 +1,3 @@
It'd be useful to be able to see what `git annex drop` would do *before* asking it to drop any files.
For example, I just set up my preferred contents expressions, and I don't know if I got them right. Before dropping anything from this repo, it'd be nice to check what would happen. I know git annex drop will only drop files that are above their minimum numcopies, but I'd still like to avoid heavyweight copying in case I got my preferred contents expressions wrong.