Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
03b21ea4b4
4 changed files with 54 additions and 0 deletions
|
@ -0,0 +1,13 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://openid.stackexchange.com/user/3ee5cf54-f022-4a71-8666-3c2b5ee231dd"
|
||||
nickname="Anthony DeRobertis"
|
||||
avatar="http://cdn.libravatar.org/avatar/1007bfece547e9f2d86fafa142cd240a62456c37f104a9d96ba9db5bf18e1934"
|
||||
subject="Looking forward to trying this"
|
||||
date="2018-04-26T13:10:30Z"
|
||||
content="""
|
||||
I use the current Android port on a few tablets, and it's... well, clearly labeled beta. On one of the tablets, it randomly segfaults [no idea if that's a git-annex bug or a hardware problem, not like I have a memtest86 available]. On both it sometimes just decides to add commits to remove files recently added on other machines (easy enough to fix with git revert). Sometimes it puts in place small placeholder files (git annex fsck fixes). Still far better than manually copying & sync'ing, though!
|
||||
|
||||
At least for me, v6 mode just doesn't work on Android — even on a new empty repository, last I checked, switching to v6 mode gave errors.
|
||||
|
||||
So I look forward to trying it in Termux!
|
||||
"""]]
|
|
@ -0,0 +1,4 @@
|
|||
Someone wrote: "Unlocked files are more difficult to synchronize (to check for
|
||||
modifications and to synchronize throught multiple remotes)." Does it mean new
|
||||
unlocked file mode V6 takes more time to find modifications? If not what is the
|
||||
drawbacks of this new unlocked file mode?
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="qiang.fang@ddaed0de00c2925f8036e6c61ce6e12654263ada"
|
||||
nickname="qiang.fang"
|
||||
avatar="http://cdn.libravatar.org/avatar/5a55c6bcb3eaacde1355f9aca0d9384a"
|
||||
subject="comment 2"
|
||||
date="2018-04-26T09:14:54Z"
|
||||
content="""
|
||||
The todo list is here
|
||||
https://git-annex.branchable.com/todo/smudge/
|
||||
"""]]
|
27
doc/forum/sync_quits_after_first_non-successfull_remote.mdwn
Normal file
27
doc/forum/sync_quits_after_first_non-successfull_remote.mdwn
Normal file
|
@ -0,0 +1,27 @@
|
|||
Hello,
|
||||
|
||||
I have observed what I think is a new behavior:
|
||||
|
||||
|
||||
% git annex add . && git annex sync --content
|
||||
commit
|
||||
Auf Branch master
|
||||
nichts zu committen, Arbeitsverzeichnis unverändert
|
||||
ok
|
||||
pull xgm
|
||||
ok
|
||||
pull horus
|
||||
ssh: Could not resolve hostname horus.local: Name or service not known
|
||||
fatal: Konnte nicht vom Remote-Repository lesen.
|
||||
|
||||
Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
|
||||
und das Repository existiert.
|
||||
failed
|
||||
copy Backgrounds/Flo Wallpaper/Cirrus_front_over_Austnesfjorden,_Austvågøya,_Lofoten,_Norway,_2015_April.jpg git-annex: unable to check horus
|
||||
|
||||
git annex sync quits with exist code 1. What I rather expect is that it tries to sync --content the other repositories. If I call `git annex sync --content S3` it sync to S3 just fine.
|
||||
|
||||
S3 is backup/client, local repo is manual/client.
|
||||
|
||||
Thanks,
|
||||
Florian
|
Loading…
Reference in a new issue