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

This commit is contained in:
Joey Hess 2014-01-01 20:37:06 -04:00
commit 020230e46d
2 changed files with 43 additions and 0 deletions

View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.227"
subject="comment 9"
date="2014-01-02T00:15:28Z"
content="""
Tobias made some good points:
* git-annex may not be in PATH depending on installation method
* It would in theory be bad if a special remote ran some git-annex command that used the special remote and ran some git-annex command [...].
* git-annex would need to tell the special remote what git repo it was being used with.
So, added GETWANTED and SETWANTED. However, if I find myself recapitulating a lot of git-annex's command-line plumbing stuff in this protocol, I will need to revisit this decision and find a better way. Particularly, I narrowly escaped an intractable dependency loop in [[!commit 8e3032df2d5c6ddf07e43de4b3bb89cb578ae048]].
"""]]

View file

@ -0,0 +1,29 @@
[[!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
"""]]