Added a comment

doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_4_cf4ed68e05fd7d553a314746b444b7c0._comment

@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 4"
+ date="2023-05-15T21:13:34Z"
+ content="""
+Exactly, I also would never want `git annex sync` to do the adding by default - strictly as an opt-in configuration.
+
+I see your point that people might have sensitive files in a repo that they don't have `.gitignore`d and would not want to get pushed. However, I argue:
+
+- If you clone a git annex repo and do `git annex sync` on it, you're pretty much already trusting that repo and the remotes. You either already have push access (that doesn't happen easily unless you're in control of the repo) or you don't, but then it's not a problem when you add your sensitive files because your changes won't ever get synced back. Even if they do at some later point: You `git annex drop --force` them (or just `git rebase -i`) to remove them from the repo entirely and worst case is that the file metadata is leaked back into the repo collection. Again, something I'd consider OK if you trust the repo.
+- When you trust a git annex repo, you also trust its `git annex config` settings like `synccontent` and consent with it.
+- Thus, if that repo has a `git annex config --set annex.syncadd true` setting that has `git annex sync` also do a prior `git annex add`, that's fine.
+
+I think that only having a local `git config annex.syncadd true` setting is basically the same as having a customized alias like mine above, so that doesn't really improve the situation: in both cases users of the repo need to do local configs. A `git annex config` will be stored in the repo and be immediately effective for everybody using it - a major benefit for collaboration, for which git annex is a golden tool. If I understand correctly, any `annex.*` config can be overridden locally with a `git config annex.*` setting (right?). So cautious users can have `git config --global annex.syncadd false` to prevent `git annex sync` from ever adding files, even if the repo is configured to do so.
+
+If the `git config annex.syncadd true` setting would just literally run `git annex add`, it automatically obeys the largefiles settings (also from the .gitattributes file).
+
+All in all I'd consider the `syncadd` a matching feature considering how much `git annex sync` is already doing: committing, pulling, merging, pushing all over the place - only the adding it doesn't do.
+
+The more behaviour can be configured in the repo directly, the better the out-of-the-box experience for (inexperienced) end users of a repo will be. I maintain many git annex repos and collaborate with different students like this on scientific projects. Together with [default preferred content expressions](https://git-annex.branchable.com/todo/Setting_default_preferred_content_expressions/) the workflow would be extremely straight-forward:
+
+[[!format  bash \"\"\"
+# get the repo
+git clone URL/repo
+cd repo
+# ”whenever you're done, run”:
+git annex sync
+# - auto-enables common remotes
+# - auto-sets preferred content expressions (to prevent the repos from uselessly downloading EVERYTHING - just what's sensible by default)
+# - auto-adds/commits/pulls/merges/pushes changes
+# - auto-syncs content around
+\"\"\"]]
+
+Sensible settings for largefiles in `.gitattributes` or the `git annex config` can be set by those who understand it, others just do `git annex sync` and are done with it.
+
+"""]]