Merge branch 'master' into sqlite

doc/todo/addunlocked_config_setting.mdwn

@@ -3,3 +3,5 @@ Can the `annex.addunlocked` be extended to have the same syntax as `annex.largef
 Basically, I want a reliable way to prevent inadvertently adding files as annexed unlocked files.
 
 Related: [[forum/lets_discuss_git_add_behavior]]
+
+> [[done]] --[[Joey]]

doc/todo/addunlocked_config_setting/comment_4_e9c9552c4f558ada76fe1e3eecfa1627._comment

@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-12-20T19:45:21Z"
+ content="""
+Made annex.addunlocked support expressions like annex.largefiles.
+
+And both of them can be set globally with `git annex config`. I did not
+make annex.addunlocked be settable by git attribute, because my sense is
+that `git annex config` covers that use case, or mostly so.
+"""]]

doc/todo/git-annex-reinject_--known_should_not_fail_when_the_file_extension_is_different.mdwn

@@ -0,0 +1,7 @@
+I noticed that with the default SHA256E backend, `git annex reinject --known FILE` will fail if FILE has a different extension than it has in the annex.  Presumably this is because `git annex calckey FILE` does not generate the same key, even though the file has the same checksum.
+
+I think it would be better if `git annex reinject --known` would ignore the file extension when deciding whether a file is known.  A case where that would be much better is caused by the fact that git-annex has changed how it determines a file's extension over time.  E.g. if foo.bar.baz was added to the annex a long time ago, it might have a key like `SHA256E-s12--37833383383.baz`.  Modern git-annex would calculate a key like `SHA256E-s12--37833383383.bar.baz` and so the reinject of the file using modern git-annex would fail.
+
+This problem does not affect `git annex reinject` without `--known`.
+
+--spwhitton

doc/todo/git-annex-reinject_does_not_work_in_a_bare_repo.mdwn

@@ -0,0 +1,28 @@
+`git annex reinject --known` doesn't work in a bare repo.
+
+    spwhitton@iris:~/tmp>echo foo >bar
+    spwhitton@iris:~/tmp>mkdir baz
+    spwhitton@iris:~/tmp>cd baz
+    spwhitton@iris:~/tmp/baz>git init --bare
+    Initialized empty Git repository in /home/spwhitton/tmp/baz/
+    spwhitton@iris:~/tmp/baz>git annex init
+    init  (scanning for unlocked files...)
+    ok
+    (recording state in git...)
+    spwhitton@iris:~/tmp/baz>git annex reinject --known ../bar
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    fatal: relative path syntax can't be used outside working tree.
+    git-annex: fd:15: hGetLine: end of file
+
+Obviously this wasn't actually a file known to git-annex.  But I get the same error in a non-dummy bare repo I am trying to reinject.
+
+A workaround is to use `git worktree add` and run `git annex reinject` from there.

doc/todo/making_it_easier_to_smudge_dotfiles/comment_3_10e03e3c90370e83f6f0999f3cd3a89f._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-12-19T20:37:18Z"
+ content="""
+How about annex.dotfiles=true enables annexing dotfiles, but only
+if annex.largefiles is set to something. Leave it up
+to the user to configure annex.largefiles according to their use case.
+And if the user neglects to annex.largefiles, this avoids blowing their foot
+off by default.
+
+annex.dotfiles could certainly go in the global `git-annex config`;
+annex.largefiles would then make sense to be set in .gitattributes,
+or also add support for storing in in `git-annex config` (which avoids
+the syntatic hacks needed to shoehorn it into .gitattributes, and makes it
+be repo-global the same as the annex.dotfiles config).
+"""]]

doc/todo/making_it_easier_to_smudge_dotfiles/comment_4_82fe6d1e4a71cdb6c283a21e52f96f88._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 4"
+ date="2019-12-21T23:03:46Z"
+ content="""
+Hmm, what would the default value of `annex.dotfiles` be?  If the default is false (so that there is no behavioural change unless the user explicitly requests it), then why not have it take effect even if annex.largefiles has not been set?
+"""]]