From 51fc969b664987475ee8dbd6b6177e8b6bdb2336 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 1 Mar 2019 16:44:34 -0400 Subject: [PATCH] notes --- doc/todo/import_tree.mdwn | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/doc/todo/import_tree.mdwn b/doc/todo/import_tree.mdwn index f50fc07d9d..3e928eaa68 100644 --- a/doc/todo/import_tree.mdwn +++ b/doc/todo/import_tree.mdwn @@ -21,17 +21,6 @@ this. * export needs to use storeExportWithContentIdentifierM for importtree=yes 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 information coming from the git-annex branch. This will allow multiple 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. * 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, or contain a "../" attack? Does git already guard against merging such @@ -48,6 +39,18 @@ this. * 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 (Some thoughts about races that the design should cover now, but kept here