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

calckey: New plumbing command, calculates the key that would be used to refer to a file

Browse source
This commit is contained in:
Joey Hess 2016-04-20 13:49:42 -04:00
parent 9d952fe9d1
commit 1bfea9b3e5
Failed to extract signature
6 changed files with 104 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

31
doc/todo/import_--reinject/comment_4_2ff1a97aea8c0a565a23d5f007e4490c._comment Normal file
View file

@ -0,0 +1,31 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2016-04-20T17:22:06Z"
content="""
I think this would fit better as an option to `git annex reinject` than
it would to `git annex import`. The latter has too many options anyway.
It would not be hard to add something like `git annex reinject
--all-known-files`, which would check if a source file hashes to a known
key and ingest its content into the annex if so, otherwise leaving the
source file along.
That would reinject files that had been added to the repo long ago, and
then were deleted. I don't know if that would be considered suprising
behavior, but it's hard to only ingest files that have a current link in
the repo (because a. git-annex keeps no such index (mostly) and b. branches and c.
tags). Even if it was surprising behavior to reinject old deleted files,
I suppose `git annex unused` could be used to drop such old unused file
contents after reinjecting them.
There's also the problem of different backends; it seems such a thing would
need to hash a file 5 different ways to make sure no hash of it is known.
As to adding plumbing, I'm always open to ideas for more useful plumbing.
* You can use `git annex find` to get eg, a list of keys of files in the
currently checked out branch.
* I've added a `git annex calckey` that can calculate the key that would be
used for a file. (eg, hashing it)
"""]]