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
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
* 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