mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2018-11-15 11:28:38 -04:00
commit 9063a0fdd7
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
7 changed files with 139 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
doc/bugs/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_6_dcfb1dfb33a690a73547a5855e0ee55d._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="my bad"
date="2018-11-15T12:34:58Z"
content="""
eh, and when you added it, I incorrectly adjusted the standalone patch in 042e20d895e022f283d7fb210e61bc19a77b0c39 by not including netbase into Depends.
I have emailed you the patch, and I think this issue could be closed with it
"""]]

69
doc/forum/assistant_to_have_synced_folders/comment_9_a7a5a4c97663211e2fb4337117ec0cb0._comment Normal file
View file

@ -0,0 +1,69 @@
[[!comment format=mdwn
username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847"
nickname="marvin"
avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
subject="comment 9"
date="2018-11-15T10:12:49Z"
content="""
$ git annex version Do 15 Nov 2018 11:05:05 CET
git-annex version: 7.20181105-gb20cea3
build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify TorrentParser MagicMime Feeds Testsuite
dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
operating system: linux x86_64
supported repository versions: 5 7
upgrade supported from repository versions: 0 1 2 3 4 5 6
then here to git configs
$ cat Downloads/ANNEX_1/.git/config
[core]
repositoryformatversion = 0
filemode = true
bare = true
logallrefupdates = true
[annex]
uuid = a39f0a5e-6019-40a1-b606-dab31c6b76bd
version = 5
direct = true
[gc]
auto = 0
[remote \"ANNEX_2\"]
url = /home/preuss/Downloads/ANNEX_2
fetch = +refs/heads/*:refs/remotes/ANNEX_2/*
annex-uuid = ba1a8311-ec01-4ae8-b94e-87be76195369
[remote \"CKCBSN0288\"]
url = ../ANNEX_2
fetch = +refs/heads/*:refs/remotes/CKCBSN0288/*
annex-uuid = ba1a8311-ec01-4ae8-b94e-87be76195369
and from the second repo
$ cat Downloads/ANNEX_2/.git/config Do 15 Nov 2018 11:11:03 CET
[core]
repositoryformatversion = 0
filemode = true
bare = true
logallrefupdates = true
[annex]
uuid = ba1a8311-ec01-4ae8-b94e-87be76195369
version = 5
direct = true
[gc]
auto = 0
[remote \"CKCBSN0288\"]
url = ../ANNEX_1
fetch = +refs/heads/*:refs/remotes/CKCBSN0288/*
annex-uuid = a39f0a5e-6019-40a1-b606-dab31c6b76bd
[remote \"ANNEX_1\"]
url = /home/preuss/Downloads/ANNEX_1
fetch = +refs/heads/*:refs/remotes/ANNEX_1/*
annex-uuid = a39f0a5e-6019-40a1-b606-dab31c6b76bd
and the worst thing is... the daemon.logs are empty.
"""]]

43
doc/forum/got_confused_by_fsck.mdwn Normal file
View file

@ -0,0 +1,43 @@
Hello,
in a clean-up spree, I removed unused content from my repos and ran fsck.
I found the behaviour of fsck surprising. I'm reporting it here to give feedback (and maybe get corrected).
I expected fsck to basically check that git annex's "recorded state" matches the actual
filesystem state (ie. expected files are present and they have the expected checksum).
fsck does that, but it also checks that the "numcopies" rule is enforced.
If I'm not mistaken, this check is quite different:
* it does not correspond to an error
* the reported issue is possibly irrelevant if the repo has an outdated view of the other remotes.
* the reported issue might be fixed by adding copies of the content to any other repo, not specificallyb to the one being fsck-ed.
Moreover, if fsck checks numcopies, I'd expect it to also check if the "required"
rule is enforced on the current repo, which it does not (tested on git annex 6.20170101.1).
Sice fixing a missing "required" file would need to add a copy to current repo, I'd consider this check more "local" than the numcopies one.
(Or alternatively, maybe fsck sould fully be "global" and report "required" rule violations about all the repos/remotes?).
Because my backup/archival repos are bare, fsck defaults to --all, and will complain
about insufficient numcopies for content that I intentionally dropped (with --unused --force).
It scared me at first, but I not
I envision several solutions to avoid those complaints:
* use --numcopies=0 (by the way, https://git-annex.branchable.com/git-annex-fsck/, states
"To verify data integrity only while disregarding required number of copies, use --numcopies=1.",
I think it should be =0)
* mark all those keys as dead (this seems time consuming)
* rewrite the git history or use git annex forget (untested, seems dangerous).
* maybe replace my backup/archival bare git repos with "directory" special remotes (less state involved).
Am I missing a better way?
PS. I attached a script illustrating the issue, together with its output.
PPS Thank you for git-annex!

8
doc/forum/got_confused_by_fsck/comment_1_ab35fea4d46ee93e62ab67e5af3dfcbf._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 1"
date="2018-11-15T02:11:43Z"
content="""
\"if the repo has an outdated view of the other remotes\" -- maybe, do git annex sync first, so that the repo has an up-to-date view of the other remotes?
"""]]

1
doc/todo/add_xxHash_backend.mdwn Normal file
View file

@ -0,0 +1 @@
From https://cyan4973.github.io/xxHash/ , xxHash seems much faster than md5 with comparable quality. There's a Haskell implementation.

1
doc/todo/keep_git-annex_branch_checked_out__63__.mdwn Normal file
View file

@ -0,0 +1 @@
Currently, the git-annex branch is not checked out, but is accessed as needed with commands like git-cat. Could git-annex work faster if it kept the git-annex branch checked out? Especially if one could designate a fast location (like a ramdisk) for keeping the checked-out copy. Maybe git-worktree could be used to tie the separate checkout to the repository.

8
doc/walkthrough/adding_a_remote/comment_8_0568e54eb04ea19d925c227268869524._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Elina_Williams"
avatar="http://cdn.libravatar.org/avatar/43c484bc0aeb53cb8d5c4dfdb3d4737a"
subject="comment 8"
date="2018-11-15T06:48:30Z"
content="""
To stimulate the USB working sometimes all you need to do is unplug and again plug it on. This is a very simple thing to do rather than any complex method. To know about more such methods and tips visit https://www.lenovosupportphonenumber.com/blog/fix-lenovo-error-code-0x80070057/
"""]]