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

doc/forum/lets_discuss_git_add_behavior/comment_26_063114bb0a29b657fd52580125a33b98._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="can git add only annex already-annexed files?"
+ date="2019-10-22T20:01:51Z"
+ content="""
+Both [[problem cases|forum/lets_discuss_git_add_behavior/#comment-cb55e3813bed92ceb6d84092841903e3]] involve `git add`'ing *already annexed* files.  So if the new `git add` behavior could be limited to already-annexed files, these problem cases would be addressed, without creating the problems discussed above.  Since already \"git-annex [[abuses|todo/git_smudge_clean_interface_suboptiomal]] the fact that git provides the clean filter with the work tree filename, and reads and cleans the file itself\", the work tree filename is known.  Question is how to know, when `git add` calls [[git-annex-clean]], which files are already-annexed.
+
+\"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.\" -- for the unlocked files, the version in the index would be the pointer file, so git-annex would know what they are.
+
+\"Suppose you have an unlocked file in your repo, and you rename it (not using git move), and then git add it.\" -- catching this requires keeping track of inodes of unlocked files.  But since already \"git-annex [[installs|todo/git_smudge_clean_interface_suboptiomal]] post-checkout, post-merge, and pre-commit hooks, which update the working tree files to make content from git-annex available\", the hooks could do this, maybe with a Bloom filter?  You'd only consult the Bloom filter if the git index entry isn't there _and_ file matches `annex.largefiles`.  Or maybe the inode info in the git index could be used.
+"""]]

doc/forum/lets_discuss_git_add_behavior/comment_27_d9923bc6cc88e66a9bf923a2fd807fd6._comment

@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="amindfv@6f75355c5dad3450ed73d1f01715be90dfdd6cd6"
+ nickname="amindfv"
+ avatar="http://cdn.libravatar.org/avatar/9cdda587f634ea9a85b34b25be421676"
+ subject="comment 27"
+ date="2019-10-23T04:24:01Z"
+ content="""
+Hi Joey --
+
+As one of the people having used the word \"hijacked\" previously, my apologies.
+
+I was trying to express frustration, surprise, and a feeling of loss of control. But I do see how my phrasing could sound too adversarial and potentially like it's ascribing something like malice where there's clearly none.
+
+For what it's worth, that's not at all the meaning I intended to convey (as I said, I very much appreciate your ongoing work!), but message received: I'm happy to change how I phrase things like that if it'll make for more constructive conversation.
+
+Thanks!
+
+"""]]

doc/forum/lets_discuss_git_add_behavior/comment_28_34a211315186fed74d3e8c22aa65f1a2._comment

@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="amindfv@6f75355c5dad3450ed73d1f01715be90dfdd6cd6"
+ nickname="amindfv"
+ avatar="http://cdn.libravatar.org/avatar/9cdda587f634ea9a85b34b25be421676"
+ subject="comment 28"
+ date="2019-10-23T04:42:36Z"
+ content="""
+> Several commenters seem to be under the misapprehension that git add of a modified file that is stored in git before will annex the new version. It does not.
+
+For what it's worth, this wasn't a misapprehension that I had in my posts above. It's possible I conflated or wasn't clear enough about other concerns in a way that created that impression (or maybe you simply weren't talking about my posts!), but my concerns are about:
+
+  - Loss of control of what's added to git vs. git-annex
+  - Violating the Principle of Least Astonishment
+  - Too much \"magic\" requiring me to work against, instead of with, my tools
+  - Breaking my and others' existing git-annex workflows
+
+All of which are relevant to adding new files to the repo.
+"""]]

doc/forum/lets_discuss_git_add_behavior/comment_29_0c8dff237acbe063b9a6268b226f2d79._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 29"
+ date="2019-10-23T15:25:30Z"
+ content="""
+Thank you for writing up the inode based clean filter idea, Joey.  And apologies from me too for 'hijacked'.
+"""]]

doc/todo/inode_based_clean_filter_for_less_surprising_git_add/comment_1_cee176c02f9103e8cfce6204827bf263._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 1"
+ date="2019-10-23T15:28:55Z"
+ content="""
+Indeed, as you say, it is not reasonable for the user to expect git-annex to do the right thing in the modify+rename case.  So this proposal seems like a great way to avoid the sort of mistakes you have brought up, without having `git add` add to the annex by default.
+"""]]