From 03a565001263ebd5a4870ec546292eba216cce4a Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Mon, 19 May 2014 16:56:15 +0000 Subject: [PATCH] Added a comment --- ...comment_4_e5516689bc128c061dcd66649dc69584._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment diff --git a/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment b/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment new file mode 100644 index 0000000000..3e2d6689c2 --- /dev/null +++ b/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="216.145.95.162" + subject="comment 4" + date="2014-05-19T16:56:15Z" + content=""" +erics, that all makes a lot of sense, except I don't know if there's actually a use case for a git-annex that behaves that way. It doesn't seem to solve the original use case. + +I'd be inclinded to instead use the new metadata support. A file could have a tag that indicates it's not strongly wanted, and if git-annex get doesn't have enough space it could seek out and drop such files. +"""]]