Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
8fa4e4ef81
6 changed files with 104 additions and 0 deletions
|
@ -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\".
|
||||
|
||||
"""]]
|
14
doc/forum/Preserving_the_v5_experience.mdwn
Normal file
14
doc/forum/Preserving_the_v5_experience.mdwn
Normal 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.
|
|
@ -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]]
|
||||
"""]]
|
|
@ -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.
|
||||
"""]]
|
|
@ -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.
|
||||
"""]]
|
|
@ -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!
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue