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

This commit is contained in:
Joey Hess 2014-09-05 17:00:23 -04:00
commit 7f5a584fb7
3 changed files with 72 additions and 1 deletions

View file

@ -0,0 +1,27 @@
### Please describe the problem.
I have an rsync remote with the following option in config:
annex-rsync-transport = ssh -i /path/to/private/key
and git annex copy --to <remote> still asks for the remote's password. I've checked and I can ssh into the remote using that key with no problems, here's the --debug output:
copy SHA256E-s152396--56bcf5e3f72daa1a194b16e42330fe82806cc1dbc6f3bb52888ff5e5c57b8d08.log (gpg) (checking <remote>...) [2014-09-05 13:12:41 CEST] read: rsync ["<user>@<remote>:<remote path>/81c/b5e/'GPGHMACSHA1--7d9470e207a5669e2d9120538b68815274dbf16d/GPGHMACSHA1--7d9470e207a5669e2d9120538b68815274dbf16d'"]
<user>@<remote>'s password:
Once it has asked for the password twice, it starts using the rsync options correctly to copy and the password is no longer needed, until the next "checking remote…". Maybe the "checking remote…" part ignores the configuration?
### What steps will reproduce the problem?
Use an rsync remote with annex-rsync-transport config set.
### What version of git-annex are you using? On what operating system?
git annex version gives:
git-annex version: 5.20140814-g9b89b5c
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS 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 webdav tahoe glacier ddar hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 0 1 2 4
which is the latest available linux-armel version.

View file

@ -0,0 +1,44 @@
Hi,
I am been seeing quite big overheads using `git-annex`. Is this is normal?
The `.git/objects` folder is explosive in my system, often being larger
than the content watched by git-annex. Here's the actual statistics
of my git-annex folders, where the fourth column is calculated as col3/(col2-col3).
[[!table data="""
folder,size,size .git,relative size
conf.annex,777536,720100,12.537433
doc.annex,20351624,11260204,1.2385528
images.annex,817064,435580,1.1418041
misc.annex,803328,572476,2.4798399
music.annex,23756116,9192740,0.63122314"""]]
That is, four of five repos require more space for the `.git` folder than the actual files. Most of this comes from the `objects` folder.
Number of files:
[[!table data="""
folder,no. files,no files .git,relative size
conf.annex,11350,9539,5.2672557
doc.annex,84954,66824,3.6858246
images.annex,92787,91285,60.775632
misc.annex,95461,95160,316.14618
music.annex,16414,13520,4.6717346
"""]]
I use the assistant web interface, and direct
mode. I use two laptops running Linux that are synchronized
directly over LAN at home or via a transfer repo on a ssh server
where git-annex is installed. The latter is set up using the web interface and the gcrypt repo.
[Mostly, the transfer repo isn't working
and I often end up with only symlinks on the computer where I did not edit the file in question,
but this is probably unrelated.]
I have previously tried to fix it using `git gc` or `git annex forget`, but it doesn't seem to significantly reduce the sizes, and what it helps isn't persistent.
Is this kind of 'overhead' something that one must accept when using
`git-annex` or do such numbers indicate that something is wrong?
Thanks.

View file

@ -5,7 +5,7 @@
system. For a backup system that uses git and that git-annex supports
storing data in, see [[special_remotes/bup]].
* git-annex is not a filesystem or DropBox clone. However, the git-annex
* git-annex is not a filesystem or Dropbox clone. However, the git-annex
[[assistant]] is addressing some of the same needs in its own unique ways.
(There is also a FUSE filesystem built on top of git-annex, called
[ShareBox](https://github.com/chmduquesne/sharebox-fs).)