annex.addunlocked support for git-annex compute
And for git-annex recompute, add the file unlocked when the original is unlocked.
This commit is contained in:
parent
de6e9f5beb
commit
23538ea17b
3 changed files with 58 additions and 42 deletions
|
@ -29,21 +29,6 @@ compute special remote. --[[Joey]]
|
|||
* allow git-annex enableremote with program= explicitly specified,
|
||||
without checking annex.security.allowed-compute-programs
|
||||
|
||||
* addcomputed should honor annex.addunlocked.
|
||||
|
||||
What about recompute? It seems it should either write the new version of
|
||||
the file as an unlocked file when the old version was unlocked, or also
|
||||
honor annex.addunlocked.
|
||||
|
||||
Problem: Since recompute does not stage the file, it would have to write
|
||||
the content to the working tree. And then the user would need to
|
||||
git-annex add. But then, if the key was a VURL key, it would add it with
|
||||
the default backend instead, and the file would no longer use a computed
|
||||
key.
|
||||
|
||||
So it, seems that, for this to be done, recompute would need to stage the
|
||||
pointer file.
|
||||
|
||||
* recompute could ingest keys for other files than the one being
|
||||
recomputed, and remember them. Then recomputing those files could just
|
||||
use those keys, without re-running a computation. (Better than --others
|
||||
|
@ -68,3 +53,4 @@ compute special remote. --[[Joey]]
|
|||
that recompute should also support recomputing non-annexed files.
|
||||
Otherwise, adding a file and then recomputing it would vary in
|
||||
what the content of the file is, depending on annex.smallfiles setting.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue