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

This commit is contained in:
Joey Hess 2019-09-27 12:47:30 -04:00
commit add8632910
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 106 additions and 0 deletions

View file

@ -0,0 +1,13 @@
I looked into post-receive hook of an arbitrary git/git-annex repo to find
[[!format sh """
(git-annex)hopa:/tmp/testds/.git/hooks[master]
$> cat post-receive
#!/bin/sh
# automatically configured by git-annex
if git annex post-receive --help >/dev/null 2>&1; then git annex post-receive; fi
"""]]
and wondered why it actually needs conditioning? `--help` runs for me longer (40-50ms) than actual `git annex post-receive` call (20ms) when there is nothing todo. So I wondered why wasting time on `--help`?
[[!meta author=yoh]]

View file

@ -0,0 +1,61 @@
[[!comment format=mdwn
username="oliv5"
avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
subject="comment 6"
date="2019-09-26T20:39:41Z"
content="""
The lock issue seems confirmed here. And the \"nobrl\" mount option solves the issue.
Maybe you should inform the user about \"nobrl\" & \"annex.pidlock\" during the \"git annex init\" filesystem check, refuse to go on and propose legacy direct mode instead if user cannot accept to have no filesystem locking ?
Without changing my mount options:
SQLite version 3.27.2 2019-02-25 16:06:06
Enter \".help\" for usage hints.
sqlite> PRAGMA journal_mode=WAL;
Error: database is locked
sqlite> create table foo (name varchar);
Error: database is locked
sqlite> insert into foo (name) values (\"joey\");
Error: no such table: foo
sqlite> .exit
After adding \"nobrl\" in the mount options:
SQLite version 3.27.2 2019-02-25 16:06:06
Enter \".help\" for usage hints.
sqlite> PRAGMA journal_mode=WAL;
wal
sqlite> create table foo (name varchar);
sqlite> insert into foo (name) values (\"joey\");
sqlite> .exit
It seems \"nolock\" is an alias for \"nobrl\", results are the same; when I put \"nolock\" in the mount options, I end up with \"nobrl\" in the \"mount\" command output.
Finally, with the \"nobrl\" mount option:
$ cd /media/mydisk/tmp/
$ date > file1
$ git init .
Dépôt Git vide initialisé dans /media/mydisk/tmp/.git/
$ git annex init test
init test
Detected a filesystem without fifo support.
Disabling ssh connection caching.
Detected a crippled filesystem.
Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
Basculement sur la branche 'adjusted/master(unlocked)'
ok
(recording state in git...)
$ git annex add file1
add file1 ok
(recording state in git...)
Hurray !
"""]]

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="smithclarkson001@2d22c4a26d6e52831b460b949377a8c9d6139a94"
nickname="smithclarkson001"
avatar="http://cdn.libravatar.org/avatar/e050ab885958a05800aa3360200e2ec1"
subject="comment 3"
date="2019-09-27T13:16:01Z"
content="""
\"Having a annex.neverlock option that plain-out rejects adding files in locked mode\" -- did you mean unlocked mode?
A related suggestion: auto-lock files after one edit
Make sense.
"""]]

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="tobiasBora"
avatar="http://cdn.libravatar.org/avatar/80a7d8c2a7b475b6b71198cce0faa6b0"
subject="Move file from git annex to just git in one commit"
date="2019-09-26T22:52:35Z"
content="""
Hello. I'd like to know, how could I move back a file managed by git annex to a normal file (for example, say I added by mistake a text file in it). For now, I do `git unlock MYFILE`, then I remove the file from git: `git rm --cached MYFILE`, and `git commit -am 'Remove file'`, and finally I add back the file, `git add MYFILE && git commit -am 'File added back in git'`. However, this creates two commits, which is a bit annoying and leave the feeling that the file has been removed while it was just a kind of modification. How could I do that in less commands, and with a single commit?
Thanks!
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="why not git-annex-sync"
date="2019-09-26T17:47:55Z"
content="""
Just curious, what makes you want to avoid using [[`git-annex-sync`|git-annex-sync]]? Without it you'd need to manually sync the [[git-annex branch|internals#The_git-annex_branch]], and merge it using [[`git-annex-merge`|git-annex-merge]].
\"what's the best way to get a repo's UUID\" -- [[`git-annex-info --fast`|git-annex-info]] prints it.
"""]]