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

This commit is contained in:
Joey Hess 2019-09-26 12:28:58 -04:00
commit 8fa4e4ef81
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 104 additions and 0 deletions

View file

@ -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\".
"""]]

View file

@ -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.

View file

@ -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]]
"""]]

View file

@ -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.
"""]]

View file

@ -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.
"""]]

View file

@ -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!
"""]]