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

4 files changed, 71 insertions, 1 deletions

diff --git a/doc/bugs/file_permissions_on___126____47__.ssh__47__config___40__windows__41__/comment_3_ff6cd2bb007d41284a09e470e060c32d._comment b/doc/bugs/file_permissions_on___126____47__.ssh__47__config___40__windows__41__/comment_3_ff6cd2bb007d41284a09e470e060c32d._comment
new file mode 100644
index 000000000..6940a80f6
--- /dev/null
+++ b/doc/bugs/file_permissions_on___126____47__.ssh__47__config___40__windows__41__/comment_3_ff6cd2bb007d41284a09e470e060c32d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5WyknJirJJridJjiPNgrlYxGG9xrZBvA"
+ nickname="Daniel"
+ subject="comment 3"
+ date="2014-01-01T23:52:32Z"
+ content="""
+No, ~/.ssh/config is fresh. I'm running git annex webapp from the git bash prompt, which is some unholy combination of msys and cygwin.
+"""]]
diff --git a/doc/todo/commit_in_direct_mode.mdwn b/doc/todo/commit_in_direct_mode.mdwn
new file mode 100644
index 000000000..1bdba2144
--- /dev/null
+++ b/doc/todo/commit_in_direct_mode.mdwn
@@ -0,0 +1,9 @@
+As of right now, the only way to commit changes to direct repositories is `git annex sync [remote]`.
+There is no way to specify what directory to operate on.
+When moving around files on a larger scale, the ability to commit specific subsets of changes would be rather nice.
+
+`git annex commit [path]` or `git annex sync [remote] -- [path]` would probably make sense.
+
+
+Thanks,
+Richard
diff --git a/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment b/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment
index 76fe450bc..bab26dc10 100644
--- a/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment
+++ b/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment
@@ -4,5 +4,40 @@
  subject="comment 1"
  date="2014-01-01T21:32:56Z"
  content="""
-.
+Such a class of repositories would be very useful, indeed.
+
+A good name would probably be, in descending order:
+
+* ephemeral
+* volatile
+* transient
+* fleeting
+
+It would be somewhere in between 'untrusted' and 'dead'.
+
+I can see two approaches working nicely, here:
+
+1. Local location log
+2. Local location log in another branch / directory
+3. No location log
+
+In the first case, location data would be added to the local location log, but any `git annex sync` or similar would parse the location log and strip out all mentions of the UUID in question.
+This would be somewhat slower when synching, but would ensure that all operations which rely on local logs operate normally.
+
+In the second case, location data would be kept in a different location.
+This would have the benefit of a clean separation and quicker merges, but induces overhead for lookups.
+On the other hand, if those lookups are wrapped cleanly, only those functions would need to know about the different locations.
+
+In the last case, no local logs would be kept.
+
+
+All in all, I think I would prefer the first option.
+
+The one thing that's hard/impossible by design is for other remotes to strip out the data.
+As the repository would not be known to other remotes, they would simply continue the carry the data.
+This can be worked around by setting the repository to "dead".
+Ephemeral repositories would not correct "dead" info about themselves; they _would_ start behaving normally once set to trusted, semit-trusted, or untrusted, though.
+
+
+Richard
 """]]
diff --git a/doc/todo/untracked_remotes/comment_2_48cc5d0e2282fa53625e0037a035fee3._comment b/doc/todo/untracked_remotes/comment_2_48cc5d0e2282fa53625e0037a035fee3._comment
new file mode 100644
index 000000000..1233a4379
--- /dev/null
+++ b/doc/todo/untracked_remotes/comment_2_48cc5d0e2282fa53625e0037a035fee3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 2"
+ date="2014-01-01T22:30:07Z"
+ content="""
+3. doesn't work because there could be a special remote or another repository that an untracked repo communicates with (forming their own little subnet hidden from the main network), and so it needs to use remote.log and location tracking for that in the usual way.
+
+It might suffice to make `git annex sync` not push any branches from an untracked repo to its remotes. Its git-annex branch would thus diverge locally, but still contain the global state. There is probably a way to make git refuse to push a branch (at least when naively running `git push` -- I never completely understand how git tracking branches work). Or a pre-push hook could be installed to block an accidential push.
+
+The uuid of an untracked repo would also leak out in the remoteuuid parameter passed to git-annex-shell. That may not matter (as long as it's not used to update the location log, which it doesn't seem to be; the remoteuuid is only used for displaying transfers AFAICS).
+
+----
+
+I'm still be worried about handling numcopies though. Suppose an untracked repo runs `git annex drop --from publicrepo`. We don't want to end up with the numcopies satisfied by the untracked repo and the other remotes that only it can access, because this would seem to make a file vanish from the public network's perspective. `git annex move` is even worse a problem, and even setting the untracked repo to untrusted or dead wouldn't help if the only copies of files are moved to it. 
+
+It seems that an untracked repo should refuse to remove content from the repositories it's \"hiding\" from, and if it's never going to git push to it, there is also no point in uploading annexed objects to it either. So, perhaps make `git.<remote>.annex-read-only = true` be used to configure a remote as read-only, and refuse to push any git branches to a read-only remote, as well as prohibit storekey and removekey being used with any read-only remote (which might be a special remote).
+"""]]