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

comment

Browse source
This commit is contained in:
Joey Hess 2023-11-30 17:07:17 -04:00
parent 3e8618fed3
commit d37219e3e5
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 31 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/forum/Revisiting_migration_and_multiple_keys.mdwn
View file

@ -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).

13
doc/forum/Revisiting_migration_and_multiple_keys/comment_2_b5545aba08c7af2f8f56caba66232c41._comment Normal file
View file

@ -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?
"""]]

17
doc/forum/Revisiting_migration_and_multiple_keys/comment_3_a712ec9b616ca45976154fd0c98ae1c4._comment Normal file
View file

@ -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.
"""]]