forum thread as requested

doc/forum/lets_discuss_git_add_behavior.mdwn

@@ -0,0 +1,6 @@
+With v7, the default behavior of `git add` in a git-annex repo changed
+to adding it as an annexed, unlocked file.
+
+It may be a little late to talk about this since v7 has become the default
+already, but I was asked to explain my thoughts on it, and I'm also
+interested in hearing your thoughts. --[[Joey]]

doc/forum/lets_discuss_git_add_behavior/comment_1_a2ebfb3f778a18872f21d72d35385ec0._comment

@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-16T18:12:07Z"
+ content="""
+My main uncertaintly about this personally has been: Why should `git add`
+add the file unlocked, and `git annex add` add the file locked? If `git add`
+adds the file to the annex, it must add it unlocked (due to git's
+interface). But `git-annex add` could behave the same as `git add` does.
+(And it can if you set annex.addunlocked.)
+
+The only half way good reason seems to be, sometimes we want the file added
+unlocked and sometimes locked, and this provides commands available by default
+with no configuration, and no added switches, for both use cases.
+"""]]

doc/forum/lets_discuss_git_add_behavior/comment_2_769e96718c6a9a4e112e424c57cf6824._comment

@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-16T18:20:00Z"
+ content="""
+But I think more people will care about the question of why
+`git add` adds files to the annex, and not to git.
+
+I had several reasons to make that the default behavior.
+
+* Suppose you have an unlocked file in your repo, and you rename
+  it (not using `git move`), and then `git add` it. Oops, now you've
+  added to git a large file that you wanted to be annexed. But
+  `mv foo bar; git add bar` is normally identical to `git mv foo bar`.
+  Why should using git-annex break that identity?
+
+* Suppose you have a mixture of unlocked files and files that are added
+  directly to git, and you've modified several of them. 
+  Now, if you run `git commit -a`, you would surely hope that the annexed
+  ones stay annexed and don't get committed directly to git.
+  Well, `git add . ; git commit` is normally equivilant, so it should
+  behave the same. It follows that `git add` does need to add some files to
+  the annex.
+
+* In general, keeping track of which files are supposed to be in the annex
+  and which in git is very failure prone. The best way seems to be for
+  git-annex to somehow be able to distinguish between them. And that's what
+  annex.largefiles lets it do. And it needs to default to adding files
+  to the annex, otherwise the above two cases can cause problems.
+
+* If `git add` does something the user doesn't want, it's
+  far preferable for the mistake to be adding the file content to the annex,
+  vs adding the file content to git. Recovery from the former is a simple
+  process (see [[tips/largefiles]] which has conversion recipes), while
+  recovery from the latter can be arbitrarily compilicated,
+  including needing to fix problems in clones on other people's computers.
+
+I think that's most of my thinking, about why `git add` behaves
+the way it does by default, although I may be forgetting something.
+
+Counterpoint: git-lfs instead recommends the user always start a repo with `git
+lfs track` the extensions that want `git add` to store in git-lfs.
+The git-lfs default is thus backwards to the annex.largefiles default,
+and they do seem to still do ok.
+"""]]

doc/tips/largefiles/comment_12_51b10d3be761afed2a95d576c2ad1964._comment

@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2019-09-16T18:43:02Z"
+ content="""
+[[forum/lets_discuss_git_add_behavior]]
+"""]]