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

doc/bugs/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment

@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 2"
+ date="2019-09-25T07:41:51Z"
+ content="""
+Sorry for the long answer delay.
+
+I tried the given commands, after fixing the \"insert\" one a little (syntax).
+
+    $ sqlite3 /media/mydisk/tmp/db
+    SQLite version 3.27.2 2019-02-25 16:06:06
+    Enter \".help\" for usage hints.
+    sqlite> create table foo (name varchar);
+    Error: database is locked
+    sqlite> .exit
+
+    $ sqlite3 /tmp/db
+    SQLite version 3.27.2 2019-02-25 16:06:06
+    Enter \".help\" for usage hints.
+    sqlite> create table foo (name varchar);
+    sqlite> insert into foo \"joey\";
+    Error: near \"\"joey\"\": syntax error
+    sqlite> insert into foo (name) values (\"joey\")
+    sqlite> .exit
+
+    $ ls -l /media/mydisk/tmp/db
+    -rw-rw---- 1 olivier users 0 sept. 25  2019 db
+
+    $ ls -l /tmp/db
+    -rw-r--r-- 1 olivier olivier 12288 sept. 25 09:29 /tmp/db
+
+    $ echo \"test\" > /media/mydisk/tmp/test
+    $ ls -l /media/mydisk/tmp/test
+    -rw-rw---- 1 olivier users 5 sept. 25 09:34 /media/wdtv/tmp/test
+
+    $ id olivier
+    uid=1000(olivier) gid=1000(olivier)
+    groupes=1000(olivier),4(adm),8(mail),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),999(spi),998(i2c),997(gpio),114(lpadmin),1001(download)
+
+The diff between /tmp and /media/mydisk/tmp is the filesystem, /tmp being in RAM. It seems that sqlite does not like the user rights and owner of files mounted by CIFS, here \"olivier:users\", even though user \"olivier\" can read/write files there and belongs to group \"users\".
+
+"""]]

doc/forum/Preserving_the_v5_experience.mdwn

@@ -0,0 +1,14 @@
+The v5 version had a few advantages over the v7 version (at least when no direct mode was involved); in particular:
+
+1. Annexed and plain git files could be kept in parallel
+2. Files that are under annex control are immediately recognized as such (in file managers by displaying a symlink icon)
+3. Never is a file readable with its wrong content (an absent file reads as ENOTFOUND rather than "/annex/...")
+4. Never do changes resulting from users' workflows (who checks out what where, who locks something) show up in the actual git history.
+
+I'd like to configure my annex repositories to give those properties, but that may need some more options:
+
+* Setting `* annex.largefiles=nothing` in `.gitattributes` restores 1 (and can still be customized)
+* Customizing it or users locking files still leaves files in their v7locked state where they can be accidentally read or otherwise look like plain available files (2-4). Having a `annex.neverlock` option that plain-out rejects adding files in locked mode or locking them would keep history and file list clean. That should be a `git annex config` option.
+* There could still be an `git annex adjust --locked` that gives users the option to have a locked adjust branch (or lock files in their own adjusted branch) without those changes propagating into every user's history.
+
+When `neverlock` is active and `git add` is run on a largefile, it could reject adding the file, place the users in a `--lock` adjusted branch, or add the file in a locked state.

doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-09-25T15:26:39Z"
+ content="""
+\"Having a annex.neverlock option that plain-out rejects adding files in locked mode\" -- did you mean unlocked mode?
+
+A related suggestion: [[todo/auto-lock_files_after_one_edit]]
+"""]]

doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-09-25T17:24:21Z"
+ content="""
+Related: [[forum/lets_discuss_git_add_behavior]]
+
+I agree that (1)-(4) were good properties.  (4) could be mitigated by using `git commit --amend` to merge the lock/unlock change with the previous commit.  But if the previous commit has been pushed to a shared repo, this could cause problems.  Something like [[todo/auto-lock_files_after_one_edit]] would restore (1)-(4), at the cost of requiring manual unlock to edit again as in v5.
+"""]]

doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-09-25T17:34:33Z"
+ content="""
+Maybe also, an option to auto-unlock the file right after commit?  E.g. based on `.gitattributes`.  Basically, unlocked files would look locally modified to `git`, but if their contents hasn't changed, the modification would just look like `typechange` from symlink to blob.  It can actually be useful to see all unlocked files this way.
+
+This of course negates the point of v7, but [[sometimes|forum/Preserving_the_v5_experience]] the v5 model is a better fit.
+"""]]

doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="amindfv@6f75355c5dad3450ed73d1f01715be90dfdd6cd6"
+ nickname="amindfv"
+ avatar="http://cdn.libravatar.org/avatar/9cdda587f634ea9a85b34b25be421676"
+ subject="comment 1"
+ date="2019-09-26T15:19:12Z"
+ content="""
+For workflow 6 (\"Manual management of git history without the synchronizer\"), how can files be synchronized across repositories?
+
+Do you still need the workflow of adding remotes and using `git annex get --from=<remote-name>`?
+
+Is it possible to do some variant of `git annex get --from=</path/to/repo>`? How about `git annex get --from=<UUID>`? (And if so, side question: what's the best way to get a repo's UUID?)
+
+Is it possible to transfer files between repos without explicitly creating remotes? If so, how? Are there gotchas when moving files \"by hand\" like permissions to be set?
+
+Thanks!
+"""]]