From 2a6824bf9dff2b7c5c78f136900465af3424ea7c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 25 Apr 2019 10:49:55 -0400 Subject: [PATCH] close --- ..._should_sync_files_deleted_from_the_remote.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/todo/Exporting_with_exporttree_should_sync_files_deleted_from_the_remote.mdwn b/doc/todo/Exporting_with_exporttree_should_sync_files_deleted_from_the_remote.mdwn index 98ddef9f56..d31b8a68f6 100644 --- a/doc/todo/Exporting_with_exporttree_should_sync_files_deleted_from_the_remote.mdwn +++ b/doc/todo/Exporting_with_exporttree_should_sync_files_deleted_from_the_remote.mdwn @@ -1,3 +1,17 @@ If git-tracked files are removed from the remote, they don't get synced over after a "git annex fsck" and "git annex export". Is there some way that they could make it to the remote? I'm imagining an rsync-like behavior to copy over files that have different time stamps or file sizes. Would such a feature be welcome in git annex? + +> Since git-annex 6.20180626, `git annex fsck --from` an exporttree=yes remote +> will notice if files on it have been deleted, and then +> `git annex sync --content` or `git-annex export` will re-upload them. +> +> But perhaps more interesting, if the remote is also configured with +> importtree=yes, `git-annex import` from it can now notice deletions +> as well as other changes to the content on the remote, and make a remote +> tracking branch in git reflecting the changes. You can then merge or +> revert the changes and export or sync can be used to put the deleted +> files back on the remote if desired. +> +> Only a subset of remotes support importree, but the fsck method +> will work for all. So, this is [[done]]. --[[Joey]]