[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
 nickname="Richard"
 subject="comment 3"
 date="2014-01-02T00:26:14Z"
 content="""
Regarding 1.: If two untracked repositories are talking to each other, they should not be tracked at all, so I don't see any issue there.
If an untracked repository communicates with a tracked one, the untracked one should still send updates for the tracked one when synching.
The solution might really simply be a specific untracked location log distinct from the rest.
This would even allow merging changes back into the main log if the user decides to track a repository after all.

Regarding pushing to tracking branches: This behavior will change soon and you can override it; see the manpage for `git-config(1)` at push.default.

Location leaks could be solved by passing `00000000-0000-0000-0000-000000000002` as UUID.
Using that UUID might also be the solution for all untracked repos as it's trivial to special case for this, but:
* What happens when you switch a known repo to untracked? What happens to its UUID in various logs? Maybe introduce a specific discard log which tries to get rid of all data concerning those UUIDs?
* What happens when you switch a repo from untracked to tracked? Simply generate (reactivate?) a UUID and switch all local occurences of `00000000-0000-0000-0000-000000000002` to the new UUID?

`git annex drop --from publicrepo` is not allowed to take local copies into account to satisfy `numcopies`, simple as that.
IMO, this is the only valid approach, as that mirrors the global view from all other repos.
For all intents and purposes, an untracked repo does not exist.


The complement, a read-only repo, would also be very useful.
Such a repo would hold data, but it would never accept location data of anywhere besides itself and the web remote.


Richard
"""]]