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

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2012-10-05 11:00:01 -04:00
commit e68600813e
4 changed files with 34 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
doc/design/assistant/blog/day_98__preferred_content/comment_1_2136618e3515d0ac6369a41f1934ec2a._comment Normal file
View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="http://meep.pl/"
ip="193.23.174.18"
subject="Ah, the barber paradox"
date="2012-10-05T06:51:11Z"
content="""
Nice. Would (not in=here) be the simplest paradoxical expression?
Is just disregarding the target repo completely during checks a possibility? This would interpret (not copies=trusted:X) as \"not in X *other* trusted repositories, no matter whether we are trusted or not\", and (not in=here) just as \"true\". I think this should generally arrive at the same results as the option 2., but by definition of the expression meaing, not by rewriting.
Alternative 3 (or is my wording different enough to be 3a?) - check that the invariant \"we have all the known files matching our PCE and only these files\" would hold after an operation before actually performing it - could be bistable if done both for gets and drops:
* (not in=here) and we do not have the file -> get thinks \"if we get it, we have a file not matching the PCE\" -> get does not get it;
* (not in=here) and we do have the file -> drop thinks \"if we drop it, there exists a file matching the PCE which we miss\" -> drop does not drop it.
This is not necessarily bad. Checking just for drops should be monostable, I guess, but doesn't it look a bit arbitrary? (Though it would be again equivalent to option 2, wouldn't it? So maybe not that arbitrary.)
"""]]

8
doc/design/assistant/desymlink/comment_3_538561d74371e53c2f8df7f5ebdf58a8._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.0.149"
subject="comment 3"
date="2012-10-05T00:43:11Z"
content="""
@Glen, for what it's worth, you can now manually \"git annex unlock\" a file and it'll stay unlocked until you manually \"git annex add\" the new version.
"""]]

2
doc/design/assistant/polls/prioritizing_special_remotes.mdwn
View file

@ -6,7 +6,7 @@ locally paired systems, and remote servers with rsync.
Help me prioritize my work: What special remote would you most like
to use with the git-annex assistant?
[[!poll open=yes 14 "Amazon S3 (done)" 9 "Amazon Glacier" 6 "Box.com" 51 "My phone (or MP3 player)" 7 "Tahoe-LAFS" 3 "OpenStack SWIFT" 14 "Google Drive"]]
[[!poll open=yes 14 "Amazon S3 (done)" 9 "Amazon Glacier" 6 "Box.com" 52 "My phone (or MP3 player)" 7 "Tahoe-LAFS" 3 "OpenStack SWIFT" 14 "Google Drive"]]
This poll is ordered with the options I consider easiest to build
listed first. Mostly because git-annex already supports them and they

8
doc/forum/special_remote_for_iPods/comment_1_37cc3dc740341cc663074fd3bfb85947._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.0.149"
subject="comment 1"
date="2012-10-05T00:39:43Z"
content="""
I've been thinking in similar directions on this page: [[design/assistant/desymlink]]
"""]]