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

This commit is contained in:
Joey Hess 2014-07-15 17:35:58 -04:00
commit 019ed359e6
13 changed files with 266 additions and 0 deletions

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 1"
date="2014-07-15T18:53:47Z"
content="""
Well, it's easy enough to make symlinks to content in a git-annex repository yourself if you want to. I don't see why this belongs in `git annex import`, which is too complicated already.
"""]]

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 4"
date="2014-07-15T19:01:24Z"
content="""
So the goal is to inject any known objects from the dump into the local annex to avoid needing to re-transfer them.
It seems to me that in this case, you would not even want to create new symlinks in the git repository.
`git annex reinject` might be a better place to put code to handle this than `git annex import`.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.2"
subject="comment 5"
date="2014-07-15T19:13:05Z"
content="""
A fundamental problem with this idea is that git-annex's keys can use any of many checksumming backends. So, which checksum should it try? Running every possible checksum on a file is going to re-read it repeatedly and be expensive.
`git annex import` avoids this problem by using whatever the default backend is configured to be for the filename it's importing. This is good enough to make repeated runs of `git annex import` work ok, but when we get into trying to reinject whole directory trees like this, I don't think that's good enough.
"""]]