From 8fc63cf1565be230f159d8e0d92e7d5b2a2aacd7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 23 Jun 2023 16:31:54 -0400 Subject: [PATCH] expand and confirm --- doc/todo/stop_after_these_files.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/todo/stop_after_these_files.mdwn b/doc/todo/stop_after_these_files.mdwn index 378c9a3411..117f926d95 100644 --- a/doc/todo/stop_after_these_files.mdwn +++ b/doc/todo/stop_after_these_files.mdwn @@ -11,3 +11,17 @@ current transfer to finish. Maybe SIGUSR1 or something like that? > An alternative approach, which avoids the complexity of needing to send a > signal, would be for git-annex to remember what transfers got > interrupted, and provide a simple command to resume them. --[[Joey]] +> +> > That could not be something like the (existing) +> > `git-annex get --incomplete`, because for that you have to remember +> > you were running a get and run effectively the same command again. +> > +> > For an interrupted `git-annex move --to foo`, it would not do to need +> > to remember what remote a file was being sent to. The goal would be +> > something like `git-annex resume` that remembers for you. +> > +> > For this, the transfer logs would need to be extended with the operation +> > and remote. + +[[!meta title="resume interrupted move/copy"]] +[[!tag confirmed]]