comment

diff --git a/doc/forum/Revisiting_migration_and_multiple_keys.mdwn b/doc/forum/Revisiting_migration_and_multiple_keys.mdwn
index 74f99d97b5641bb3a7571a660574246c7202681c..13e009d2feee1696958207cfc91720c3530a5ca6 100644 (file)
--- a/doc/forum/Revisiting_migration_and_multiple_keys.mdwn
+++ b/doc/forum/Revisiting_migration_and_multiple_keys.mdwn
@@ -1,7 +1,7 @@
 I have several workflows that rely on regular key migrations, and I would love to explore some ways that migrating keys could be improved.
 
 I see there has already been discussion about this:
-https://git-annex.branchable.com/todo/alternate_keys_for_same_content/
+[[todo/alternate_keys_for_same_content]]
 
 I don't know how often this comes up, but it comes up a lot for me. I have several data sources that I regularly index and mirror by constructing keys based on md5 and size, and assemble a repo with the known filename. (gdrive, many software distribution sites, and others).
 

diff --git a/doc/forum/Revisiting_migration_and_multiple_keys/comment_2_b5545aba08c7af2f8f56caba66232c41._comment b/doc/forum/Revisiting_migration_and_multiple_keys/comment_2_b5545aba08c7af2f8f56caba66232c41._comment
new file mode 100644 (file)
index 0000000..5c15c5c
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys/comment_2_b5545aba08c7af2f8f56caba66232c41._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-11-30T20:49:53Z"
+ content="""
+There seem to be difficulties with both performance and with security in
+storing information in the git-annex branch to declare that one key
+is replaced by another one.
+
+I wonder if there are any pain points that could be handled better without
+recording such information in the git-annex branch. What do your helper
+scripts do?
+"""]]

diff --git a/doc/forum/Revisiting_migration_and_multiple_keys/comment_3_a712ec9b616ca45976154fd0c98ae1c4._comment b/doc/forum/Revisiting_migration_and_multiple_keys/comment_3_a712ec9b616ca45976154fd0c98ae1c4._comment
new file mode 100644 (file)
index 0000000..8fa8420
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys/comment_3_a712ec9b616ca45976154fd0c98ae1c4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-11-30T20:55:02Z"
+ content="""
+I wonder if it would suffice to have a way for git-annex to record that key
+A migrated to B, but not treat that as meaning that it should get B's
+content when it wants A, or vice-versa.
+
+Instead, when a repository learns that A was elsewhere migrated to B, it
+could hardlink its content for A to B and update the location log for
+B to say is has a copy. The same as if `git-annex migrate` were run locally.
+(It could even hash the content and verify it got B.)
+
+That wouldn't help if a special remote has the content of A, and 
+git-annex wants to get the content of B.
+"""]]