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-12-17 19:40:18 -04:00
commit 8462e3787c
12 changed files with 192 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

82
doc/bugs/Android:_does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__.mdwn Normal file
View file

@ -0,0 +1,82 @@
### Please describe the problem.
Seems to not upload files from Android client (set to "Manual mode: only stores files you...") to servers configured to get the files despite "syncing enabled"
Even when I chose "File source:" mode -- it just dropped all locally stored ones and didn't transfer those I have added.
### What steps will reproduce the problem?
Add file to the sdcard (vfat), and see it added to git (annex) but not uploaded
### What version of git-annex are you using? On what operating system?
Android build as now of Dec 13 I believe
### Please provide any additional information below.
First it just said that nothing to be transfered, I have switched that remote to "Full backup", web dashboard had "Scanning for files to transfer" for a while, then refreshed with "Synced with" and no file transfers running. Below is an excerpt from the log
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
(Recording state in git...)
(Recording state in git...)
(Recording state in git...)
add pics/20131217_125740.jpg ok
add pics/20131217_125740.jpg [2013-12-17 16:19:25 EST] Committer: Committing changes to git
[2013-12-17 16:19:25 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Invalid pid specified
Invalid pid specified
warning: no threads support, ignoring --threads
Already up-to-date.
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
bcb7ed7..3672b38 git-annex -> synced/git-annex
e8cc37f..052b758 annex/direct/master -> synced/master
Already up-to-date.
[2013-12-17 16:19:29 EST] Committer: Adding 20131217_125726.jpg
ok
(Recording state in git...)
(Recording state in git...)
add pics/20131217_125726.jpg ok
add pics/20131217_125726.jpg [2013-12-17 16:19:30 EST] Committer: Committing changes to git
Invalid pid specified
[2013-12-17 16:19:32 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Already up-to-date.
warning: no threads support, ignoring --threads
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
3672b38..f914fed git-annex -> synced/git-annex
052b758..859d3c6 annex/direct/master -> synced/master
Already up-to-date.
Invalid pid specified
Invalid pid specified
Invalid pid specified
# End of transcript or log.
"""]]
previous runs experienced different problems, so may be those could lead to unreported problem here?
e.g. from previous run:
[[!format sh """
[2013-12-17 16:04:44 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex
Already up-to-date.
warning: no threads support, ignoring --threads
warning: no threads support, ignoring --threads
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
a889d7b..c9a7466 git-annex -> synced/git-annex
error: Ref refs/heads/synced/git-annex is at c9a74663dc863eb95d316deac4657173c92653df but expected a889d7b335738ef1c4f85da18d1bea337cd36522
remote: error: failed to lock refs/heads/synced/git-annex^[[K
To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/
! [remote rejected] git-annex -> synced/git-annex (failed to lock)
error: failed to push some refs to 'ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/'
Everything up-to-date
Invalid pid specified
[2013-12-17 16:08:34 EST] main: Syncing with vagus.cns.dartmouth.edu_annex
Everything up-to-date
Invalid pid specified
~
]]

4
doc/bugs/feature_request:_addhash.mdwn
View file

@ -13,9 +13,9 @@ I have a big repo of files I have added using `addurl --fast`. I download the fi
### Workaround
In both these cases, what I can do is unlock (maybe?) or unannex (definitely) all of the files, and then re-add them using the new hash. In both cases this means I now risk having duplicates in various clones of the repo, and would have to clean them up with `drop-unused` -- after first having re-copied them from a repo that has them under the new hash. I also lose the continuity of the history of that object.
In both these cases, what I can do is <del>unlock (maybe?) or unannex (definitely) all of the files, and then re-add them using the new hash</del> <em>use `migrate` to relink the files using the new scheme</em>. In both use cases this means I now risk having duplicates in various clones of the repo, and would have to clean them up with `drop-unused` -- after first having re-copied them from a repo that has them under the new hash <em>or `migrate`d them in each clone using the pre-migration commit; Either way is problematic for special remotes, in particular glacier</em>. I also lose the continuity of the history of that object.
In use case 2 I also lose the URLs of the files and would have to re-add them using `addurl`.
<del>In use case 2 I also lose the URLs of the files and would have to re-add them using `addurl`.</del> <em>This is probably not true when using `migrate`.</em>
... which brings me to the proposed feature.

8
doc/bugs/feature_request:_addhash/comment_2_7b712786c580dd1ca24479664c31eed6._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://id.clacke.se/"
nickname="clacke"
subject="Re: git annex migrate"
date="2013-12-17T22:04:09Z"
content="""
`migrate` replaces the manual work described in \"Workaround\", but has the drawback described in its own manual -- the content is now available under two keys in the annex. This proposal adds one layer of abstraction to avoid that duplication. It's entirely possible that this layer of abstraction is a bad idea with horrible complexity and/or performance issues, but I wanted to put this idea out there.
"""]]

10
doc/devblog/day_81__more_standalone/comment_1_25ceb116406b55a8ff28f7b392806bc9._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnRai_qFYPVvEgC6i1nlM1bh-C__jbhqS0"
nickname="Matthew"
subject="Binaries"
date="2013-12-17T12:49:26Z"
content="""
Are there binaries for the RPi version anywhere, it would be great to try it.
Thanks
"""]]

6
doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__.mdwn Normal file
View file

@ -0,0 +1,6 @@
Hi,
I accidentally removed the .git/ folder inside a git annex assistant-monitored folder. When I open the assistant web app it still shows the repository but when I try to select it the page request never returns. What can I do at this point? I was thinking I can remove the repository from the git annex assitant configuration file if it is a plain-text file, but I don't know of its location. Please advise.
Regards,
Blake

10
doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__/comment_1_5baffd4d6994bbcb23614b17777a0ffe._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="comment 1"
date="2013-12-17T16:07:00Z"
content="""
The file you need is .config/git-annex/autostart in your home directory.
Once deleted, re-running the assistant should let you re-create the git repository and it'll re-add your files.
"""]]

34
doc/forum/new_linux_arm_tarball_build/comment_3_2702cdbae4179a7a103d2a7098a8ed5e._comment Normal file
View file

@ -0,0 +1,34 @@
[[!comment format=mdwn
username="http://julien.lefrique.name/"
nickname="jlefrique"
subject="QNAP"
date="2013-12-17T07:57:37Z"
content="""
Hi Joey,
Thank you for taking the time to setup an ARM build. I am trying to run the last standalone build on a QNAP TS-219PII. I get the following error. Do you have any ideas?
$ uname -a
Linux willow 2.6.33.2 #1 Fri Mar 1 04:41:48 CST 2013 armv5tel unknown
$ ./runshell
$ cd ../annex
$ git annex version
git-annex version: 5.20131216-g07252d6
build flags: Assistant Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web glacier hook
local repository version: 3
default repository version: 3
supported repository versions: 3 5
upgrade supported from repository versions: 0 1 2 4
$ git annex info
repository mode: indirect
trusted repositories: fatal: cannot get RLIMIT_NOFILE: Bad address
fatal: cannot get RLIMIT_NOFILE: Bad address
fatal: cannot get RLIMIT_NOFILE: Bad address
fatal: cannot get RLIMIT_NOFILE: Bad address
fatal: cannot get RLIMIT_NOFILE: Bad address
fatal: cannot get RLIMIT_NOFILE: Bad address
I am still using the version 3.8.3 of the QNAP distribution. I will try to update to the last version (4.0.5) to see if it helps.
"""]]

10
doc/forum/new_linux_arm_tarball_build/comment_4_e1d802fbcc9d699ece5267e80990255a._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="RLIMIT_NOFILE"
date="2013-12-17T16:05:12Z"
content="""
This is clearly failing when it runs git. Looking at the git source code, it does have a `RLIMIT_NOFILE` ifdef, so I could disable this, but would have to maintain my own build of git.
What kernel version is this? Upgrading is likely to fix it.
"""]]

9
doc/forum/new_linux_arm_tarball_build/comment_5_257b91ecbf5a6040a8e4c9a360c775ba._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="http://julien.lefrique.name/"
nickname="jlefrique"
subject="QNAP kernel"
date="2013-12-17T16:27:21Z"
content="""
It's kernel 2.6.33.2 (see uname in my previous message).
A new version with kernel 3.4.x is available, I will try to update when the data on my NAS will be (more) safely backup-ed.
"""]]

12
doc/tips/what_to_do_when_you_lose_a_repository/comment_5_4fb04b70d88ec93ff9ed4f884747d5d4._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
nickname="Mica Semrick"
subject="forget command"
date="2013-12-17T05:52:52Z"
content="""
Unfortunately, I plugged in the drive and it was alive just long enough to clone the repo and pull down about half of the data. Then it just started clicking. I did my best to wipe the drive before I returned it, but it didn't even make it that far.
Now I've got a replacement drive. Since my system auto-mounts based on the partition label; I had been using the label to identify external drives. So I want to describe the drive the same way to my system & git-annex.
In this case, I think I'd like to completely get rid of any notion the repos have of the old drive.
"""]]

8
doc/tips/what_to_do_when_you_lose_a_repository/comment_6_05db504cbff2ec2a6346bf43e57a3c25._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="comment 6"
date="2013-12-17T16:11:52Z"
content="""
You could use `git annex forget --drop-dead` in that situation, but what I would do is first `git annex describe lostremote \"my old drive that I lost\"` and then set up the replacement drive with whatever description you had before.
"""]]

1
doc/todo/Android:_add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__.mdwn Normal file
View file

@ -0,0 +1 @@
Having it named starting with "Add to ..." would improve its convenience visibility (would even position before "Add to Dropbox" ;) )