mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment

Browse source
This commit is contained in:
http://joeyh.name/ 2012-10-05 15:08:26 +00:00 • committed by admin
parent e68600813e
commit 4c5443329a
1 changed files with 14 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

14
doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment Normal file
View file

@ -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.
"""]]