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

This commit is contained in:
Joey Hess 2016-05-20 12:44:32 -04:00
commit 9ac7e833cd
Failed to extract signature
8 changed files with 120 additions and 0 deletions

15
doc/bugs/.mdwn Normal file
View file

@ -0,0 +1,15 @@
A default cabal install on OS X in a sandbox of git-annex 6.20160511 will result in no S3 support, as reported to Homebrew in the following two issues:
https://github.com/Homebrew/homebrew-core/issues/1268
https://github.com/Homebrew/legacy-homebrew/issues/47737
The underlying cause is that aws-0.13.0 lacks commit https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d, which allows data-default 0.6.
I attempted to mitigate the issue using --flags="s3", but that does not seem to help (nor does it force the build to fail): still no s3 support. I'd expect that either to constrain data-default to 0.5.3 and produce a build with s3 support, or fail the build, but for some reason it doesn't. Is this not working because we're in a sandbox or some other reason?
Currently, I'm planning to just patch aws with https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d rather than resorting to a fixed configuration (e.g., lts-5.5 or whatever), as you can see here:
https://github.com/Homebrew/homebrew-core/pull/1307
It would be great if git-annex could work around the issue itself, though.
Meanwhile, I have also pinged aws to request a 0.13.1 release, which would solve the problem "the right way":
https://github.com/aristidb/aws/issues/202

View file

@ -0,0 +1,24 @@
### Please describe the problem.
The assistant keeps making merges that deletes all the files in the repository. I "git revert" the merge commit, but the next day it does it again. It also seems to have gone into a merge loop before this happens (will post a screenshot of tig). I can make the repo available privately if that will help.
### What steps will reproduce the problem?
Unknown. It does it on its own without me even interacting with files in the annex.
### What version of git-annex are you using? On what operating system?
The host that keeps deleting is running 6.20160428-g1f253e8 on ArchLinux (x86_64). A remote that it keeps syncing with is running 6.20160511-g4633f0b, also on ArchLinux x86_64.
### Please provide any additional information below.
[[!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
Updating 8cb69d3..c589c5e
Fast-forward
.gitignore | 3 ---
Bilete/8mars-2013-1.jpg | 1 -
etc.
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I use git-annex for everything. I've got 10 repositories and around 2.5TB of data in those repos which in turn is synced all over the place. It's excellent.

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="EskildHustvedt"
subject="comment 1"
date="2016-05-20T07:45:52Z"
content="""
Right, so I forgot to mention, perhaps crucially. I'm using v6 for these repos.
Here's the tig grap for master: [[https://ssl.zerodogg.org/~zerodogg/tmp/annexmerge1-2016-05-20.png]]
Here's the merge commit itself for master: [[https://ssl.zerodogg.org/~zerodogg/tmp/annexmerge2-2016-05-20.png]]
"""]]

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="xloem"
subject="comment 2"
date="2016-05-18T09:43:13Z"
content="""
Thanks. It turns out I'd deleted that repo in order to free the inodes up. Next time I will see if I can repair.
But it would be nice if git-annex tracked inodes the way it tracks free space, so that it could refrain from causing the inode exhaustion. This also would have alerted me to how few inodes I had remaining.
"""]]

View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="xloem"
subject="dangling objects"
date="2016-05-18T01:49:11Z"
content="""
My repos have accumulated thousands of dangling objects recently (every one). I'm wondering, would this issue be resolved with the syncing fix? If so, should the objects just be deleted?
"""]]

View file

@ -0,0 +1,42 @@
[[!comment format=mdwn
username="Gus"
subject="Thank you"
date="2016-05-19T11:27:15Z"
content="""
The external unit seems to hold a NTFS. Here is the `git-annex info` output:
repository mode: direct
trusted repositories: 0
semitrusted repositories: 4
00000000-0000-0000-0000-000000000001 -- web
00000000-0000-0000-0000-000000000002 -- bittorrent
069de9a2-dc53-4c0a-82e0-a61a1f29e6b3 -- stratus PC [stratus]
49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [here]
untrusted repositories: 0
transfers in progress: none
available local disk space: 4.42 gigabytes (+1 megabyte reserved)
local annex keys: 5556
local annex size: 1.66 terabytes
annexed files in working tree: 6618
size of annexed files in working tree: 1.1 terabytes
bloom filter size: 32 mebibytes (1.1% full)
backend usage:
SHA256E: 6618
However, `git status` says:
fatal: This operation must be run in a work tree
Which is not the same message as \"no git found here\", but is also not what I expected to see. `git log` seems to work but says nothing about the file at hand.
On the PC side, however, I can see three commits on the file (I wish the commit message contained the command line with arguments, rather than the less descriptive \"git-annex in Toshiba USB HDD\").
Using `git show` and `git cat-file` I managed to determine the following:
March 4: the initial version of the file was committed.
May 17 11:51: the file's content changed to `../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/kx/3W/SHA256E-s96418--c6164e17d88914b2e6781e2cb8e7b91e9669ddf2d9ee6f5cbb17f3212bccfba4.jpg/SHA256E-s96418--c6164e17d88914b2e6781e2cb8e7b91e9669ddf2d9ee6f5cbb17f3212bccfba4.jpg`. This is blob `../.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg`.
May 17 12:22 the file's content changed again to `../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg`, i.e., a reference to the previous object. This is blob `../.git/annex/objects/ZQ/WF/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg`.
What else can I do in order to work out what went wrong? Is having concurrent commands manipulating the same repository a bad idea?
"""]]

View file

@ -0,0 +1,3 @@
I was trying to copy files which failed to copy (3 out of 6,000) to remote host after copy -J4. Succeeded. But with subsequent runs, apparently even with copy --fast it takes annex 10 sec for annex to realize there is nothing to copy. git ls-files which annex calls returns list immediately, so it is really some parsing/access to data under git-annex branch which takes awhile. I think we had similar discussion before but couldn't find. So I wondered to whine again to see if some optimization is possible to make --fast copies faster, especially whenever there is nothing to copy.
[[!meta author=yoh]]

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="xloem"
subject="Freenet Special Remote"
date="2016-05-19T03:02:18Z"
content="""
The freenet external special remote at https://github.com/xloem/gitlakepy is working now.
No bells and whistles, but you can install it and start git-annex copy --to=freenet and git-annex get --from=freenet .
"""]]