]> dgit.raspbian.org Git - git-annex.git/commitdiff
update
authorJoey Hess <joeyh@joeyh.name>
Sun, 4 Aug 2024 15:34:00 +0000 (11:34 -0400)
committerJoey Hess <joeyh@joeyh.name>
Sun, 4 Aug 2024 15:34:00 +0000 (11:34 -0400)
Decided not to use the annexobjects location for exportTempName.

There doesn't seem to be any actual benefit to doing that, because an
export that renames to exportTempName always renames it back from that
to another location.

Also the annexobjects directory won't actually help with the paired
rename issue.

doc/todo/exporttree_remotes_could_store_any_key.mdwn
doc/todo/git-annex_proxies.mdwn

index 0762ae9172953a3df84d7d498a5bfe7731fcb35b..2184123e02c56f64a681f576a26d1637544c99a1 100644 (file)
@@ -16,9 +16,6 @@ keys, in order to support exporttree=yes remotes.
 Another place this would be useful is 
 [[proxying to exporttree=yes special remotes|design/passthrough_proxy]].
 
-This could also solve [[todo/export_paired_rename_innefficenctcy]]
-cleanly.
-
 With this change, a user could just `git-annex copy --to remote`
 and copy whatever files they want into it. Then later 
 `git-annex export master --to remote` would efficiently update the tree
@@ -90,7 +87,7 @@ If the annexobjects directory only gets keys uploaded to it, and never had
 exported files renamed into it, its content will always be as expected, and
 perhaps the remote does not need to be untrusted.
 
-OTOH, if an exported file that is being deleted (or pairwise renamed) in an
+OTOH, if an exported file that is being deleted in an
 updated export gets renamed into the annexobjects directory, it's possible
 that the file has in fact been overwritten with other content (by git-annex
 in another clone of the repository), and so the object in annexobjects
index b7fa222717a0ea5d08499bde341a59e49c11ea5c..523f1a1661d66abc4a48c54706a3a2cbcc4e895b 100644 (file)
@@ -33,8 +33,12 @@ Planned schedule of work:
 * Working on `exportreeplus` branch which is groundwork for proxying to
   exporttree=yes special remotes.
 
-* `git-annex export` when renaming an exported file to a temporary name
-  should use the annexobjects location.
+* `git-annex export` when unexporting a deleted file from the tree should
+  rename it to the annexobjects location. This would avoid needing to
+  re-upload it again in the case where it's preferred content of the
+  remote. Currently eg, a sync will unexport the file and then re-upload
+  it. If it's not preferred content, sync will drop it from the
+  annexobjects location.
 
 ## items deferred until later for p2p protocol over http