From 708add47c47a9e529d65bccfb49fa87db74401c6 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Fri, 5 Oct 2012 15:08:26 +0000 Subject: Added a comment --- .../comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment diff --git a/doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment b/doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment new file mode 100644 index 000000000..fa1ce32b8 --- /dev/null +++ b/doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.154.0.149" + subject="comment 2" + date="2012-10-05T15:08:26Z" + content=""" +Yes, I think checking the future only for drops is both stable and equivilant to the other choices. + +Disregarding the target solves the problem for the current set of expressions. There may be future expressions or operations where that does not hold. For example, if move supported --auto (which it does not), you'd need to disregard both sides. + +That method would make it impossible to do some possibly useful things. \"in=here or (not copies=3)\" + +The real problem with it is that existing options like --copies and --in already take all repos into account, so this would potentally lead to two divergent DSLs being used by git-annex, which would probably be confusing. +"""]] -- cgit v1.2.3