From 7ea7ae34f641c8d0154c43043499f7221f06f1c7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 13 Jun 2025 08:34:47 -0400 Subject: [PATCH] response --- ..._1d560f2c337e5f067f42a3088e686467._comment | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/forum/Import_-_Changing_Largefiles/comment_1_1d560f2c337e5f067f42a3088e686467._comment diff --git a/doc/forum/Import_-_Changing_Largefiles/comment_1_1d560f2c337e5f067f42a3088e686467._comment b/doc/forum/Import_-_Changing_Largefiles/comment_1_1d560f2c337e5f067f42a3088e686467._comment new file mode 100644 index 0000000000..85cf6c1417 --- /dev/null +++ b/doc/forum/Import_-_Changing_Largefiles/comment_1_1d560f2c337e5f067f42a3088e686467._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2025-06-13T12:27:35Z" + content=""" +git-annex has to maintain a considerable amount of state about the content +of a special remote in order to efficiently import trees from it, and this +caching is what is preventing the new configuration of annex.largefiles +from being used. + +In particular, git-annex knows the content identifier associated with the +file you imported before. And the key associated with that content +identifier is present in the repository. So it uses the existing content +rather than download it again. + +While it would be possible to either remove enough information from the +git-annex branch to defeat that, or modify git-annex to have a mode where +it redoes expensive work, it seems to me to be easier to just treat this as +a case of an annexed file that you want to change to be stored in git +instead. Since that is a general problem, with a general solution. See +[[tips/largefiles]], "converting annexed to git". +"""]]