From 33712dbc993136c7fd95764ef24395b1a7649ae4 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 17 Jul 2015 11:48:17 -0400 Subject: comment --- ...comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment diff --git a/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment b/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment new file mode 100644 index 000000000..83af05970 --- /dev/null +++ b/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-07-17T15:41:53Z" + content=""" +I don't feel that migration is an important enough feature to complicate +the rest of git-annex with special handling of multiple keys that point to +the same content. + +You could have used `mv` in your use case to move the repo to the new drive +while preseving hard links. + +What might be useful is for `git annex migrate` to write a list of the old keys +someplace. These could then be dropped when the user wants to get rid of them, +with mixing them up with other unused files. Although if you care about old +versions of files and don't want to drop them as unused, it seems to me you'd +also want to be able to access the old keys from before the migration. +"""]] -- cgit v1.2.3