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.
This commit is contained in:
Joey Hess 2024-08-04 11:34:00 -04:00
parent ee076b68f5
commit 6b63449133
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 7 additions and 6 deletions

View 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

View 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