summaryrefslogtreecommitdiff
path: root/doc/tips
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-04-05 13:04:02 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-04-05 13:22:35 -0400
commit2d8cbcafa66a317fcb3d571cd8bf45962d651998 (patch)
tree9c39bb0de77d3570e403d29acc99ac04ead4de89 /doc/tips
parentd3f440e599ee0271a7a6e8c441e5d00b3c9548e3 (diff)
Added remote.<name>.annex-push and remote.<name>.annex-pull
The former can be useful to make remotes that don't get fully synced with local changes, which comes up in a lot of situations. The latter was mostly added for symmetry, but could be useful (though less likely to be). Implementing `remote.<name>.annex-pull` was a bit tricky, as there's no one place where git-annex pulls/fetches from remotes. I audited all instances of "fetch" and "pull". A few cases were left not checking this config: * Git.Repair can try to pull missing refs from a remote, and if the local repo is corrupted, that seems a reasonable thing to do even though the config would normally prevent it. * Assistant.WebApp.Gpg and Remote.Gcrypt and Remote.Git do fetches as part of the setup process of a remote. The config would probably not be set then, and having the setup fail seems worse than honoring it if it is already set. I have not prevented all the code that does a "merge" from merging branches from remotes with remote.<name>.annex-pull=false. That could perhaps be done, but it would need a way to map from branch name to remote name, and the way refspecs work makes that hard to get really correct. So if the user fetches manually, the git-annex branch will get merged, for example. Anther way of looking at/justifying this is that the setting is called "annex-pull", not "annex-merge". This commit was supported by the NSF-funded DataLad project.
Diffstat (limited to 'doc/tips')
-rw-r--r--doc/tips/semi-synchronized_remotes/comment_1_d0459d72b7e0441fe833a5c8e1588a4f._comment19
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/tips/semi-synchronized_remotes/comment_1_d0459d72b7e0441fe833a5c8e1588a4f._comment b/doc/tips/semi-synchronized_remotes/comment_1_d0459d72b7e0441fe833a5c8e1588a4f._comment
new file mode 100644
index 000000000..0a6aeb9d6
--- /dev/null
+++ b/doc/tips/semi-synchronized_remotes/comment_1_d0459d72b7e0441fe833a5c8e1588a4f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-05T16:11:57Z"
+ content="""
+Setting `remote.<name>.annex-readonly=true` prevents git-annex sync
+from pushing changes to the remote. It also prevents any git-annex command
+from copying annexed file contents to the remote, or deleting annexed file
+contents. So I think it's ideal for this kind of situation.
+
+There does seem to be room for configs to prevent sync from pulling/pushing
+without making the remote fully readonly. For example, the remote might be
+a source of content, that only knows about the files it added and not other
+files in the local repository, so dropping files from it should be allowed
+but not pushing to it.
+
+So, I've added `remote.<name>.annex-push` and
+`remote.<name>.annex-pull`.
+"""]]