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

notes

Browse source
This commit is contained in:
Joey Hess 2019-03-01 16:44:34 -04:00
parent 18d7a1dbbb
commit 51fc969b66
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 14 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
doc/todo/import_tree.mdwn
View file

@ -21,17 +21,6 @@ this.
* export needs to use storeExportWithContentIdentifierM for importtree=yes * export needs to use storeExportWithContentIdentifierM for importtree=yes
remotes remotes
* "git annex import master --from rmt" followed by "git annex import master:sub --from rmt"
first makes the tracking branch contain only what's in the remote,
and then grafts what's in the remote into a subdir. Is that the behavior
a user would expect, or would they instead expect that importing to a new
place starts the tracking branch over fresh on the contents of master?
Hmm, one way to look at it is that if there was a merge from
refs/remotes/rmt/master in between the two commands, and then after, the
result would be the same as if there was only a merge after. So the
current behavior seems to make sense.
* Database.ContentIdentifier needs a way to update the database with * Database.ContentIdentifier needs a way to update the database with
information coming from the git-annex branch. This will allow multiple information coming from the git-annex branch. This will allow multiple
clones to import from the same remote, and share content identifier clones to import from the same remote, and share content identifier
@ -41,6 +30,8 @@ this.
ContentIdentifier that is not already known in the database. ContentIdentifier that is not already known in the database.
* When on an adjusted unlocked branch, need to import the files unlocked. * When on an adjusted unlocked branch, need to import the files unlocked.
Also, the tracking branch code needs to know about such branches,
currently it will generate the wrong tracking branch.
* What if the remote lists importable filenames that are absolute paths, * What if the remote lists importable filenames that are absolute paths,
or contain a "../" attack? Does git already guard against merging such or contain a "../" attack? Does git already guard against merging such
@ -48,6 +39,18 @@ this.
* Need to support annex.largefiles when importing. * Need to support annex.largefiles when importing.
* If a tree containing a non-annexed file is exported,
and then an import is done from the remote, the new tree will have that
file annexed, and so merging it converts to annexed (there is no merge
conflict). This problem seems hard to avoid, other than relaying on
annex.largefiles to tell git-annex if a file should be imported
non-annexed.
Although.. The importer could check for each file,
if there's a corresponding file in the branch it's generating the
import for, if that file is annexed. But this might be slow and seems a
lot of bother for an edge case?
## race conditions ## race conditions
(Some thoughts about races that the design should cover now, but kept here (Some thoughts about races that the design should cover now, but kept here