close as distributed migration meets this use case
This commit is contained in:
parent
5e4d92efd5
commit
aba87a6e92
2 changed files with 16 additions and 0 deletions
|
@ -3,3 +3,5 @@ Currently, git-annex-migrate leads to content (and metadata) being stored under
|
||||||
More generally, git-annex-replace could be implemented this way, doing what git-replace does, but for git-annex keys rather than git hashes. [[git-annex-pre-commit]] might need to be changed to implement replacement of keys added later.
|
More generally, git-annex-replace could be implemented this way, doing what git-replace does, but for git-annex keys rather than git hashes. [[git-annex-pre-commit]] might need to be changed to implement replacement of keys added later.
|
||||||
|
|
||||||
[[!tag needsthought]]
|
[[!tag needsthought]]
|
||||||
|
|
||||||
|
> [[wontfix|done]], use distributed migration instead --[[Joey]]
|
||||||
|
|
|
@ -0,0 +1,14 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 2"""
|
||||||
|
date="2024-02-10T14:22:31Z"
|
||||||
|
content="""
|
||||||
|
In the meantime, distributed migration has been implemented, allowing
|
||||||
|
to `git-annex migrate --update` to catch up with all migrations that were
|
||||||
|
started elsewhere.
|
||||||
|
|
||||||
|
This is essentially the same goal, and it is much more efficient in terms
|
||||||
|
of storage than git-replace of a large number of refs.
|
||||||
|
|
||||||
|
So, I'm going to close this.
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue