diff options
Diffstat (limited to 'doc')
4 files changed, 79 insertions, 0 deletions
diff --git a/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn b/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn new file mode 100644 index 000000000..cb3c7ef81 --- /dev/null +++ b/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn @@ -0,0 +1,40 @@ +### Please describe the problem. +massive repo, max cpu using + + git annex add . + +had to interrupt the job as it was processing 1 small file per 5 seconds after about 3h run. + +I am running it on the root of a large (currently 1TB) exFAT-based drive used for archiving + +The repo grew to 28G. + +Is this a regular issue with exFAT? I've done quite a bit of searching. I'll do more. + +### What steps will reproduce the problem? +- install on El Capitan (latest) via homebrew +- create 1TB exFAT file store +- follow walk through to setup annex locally and on external +- add + +### What version of git-annex are you using? On what operating system? +git-annex version: 6.20160126 +build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser Feeds Quvi +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 SHA1E SHA1 MD5E MD5 WORM URL +remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external + +El Capitan 10.11.3 + + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) +I'd love to say I have. You'll hear my shout of joy when I do. diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment new file mode 100644 index 000000000..d663f3370 --- /dev/null +++ b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="mih" + subject="Thanks" + date="2016-03-02T19:30:49Z" + content=""" +Thanks for investigating this further. + +One aspect that may make switching the location of the .git directory into the worktree of the submodule less desirable is this: With the actual .git in ../.git/modules/... one can easily rm -rf the submodule, deinit it, and re-init/update from the (still present) ../.git/modules/... at a later point in time. Especially, when a submodule is a more complicated beast (e.g. with multiple configured remotes) the required steps to regenerate the same setup get more complex. +"""]] diff --git a/doc/forum/How_to_shrink_transfer_repo__63__.mdwn b/doc/forum/How_to_shrink_transfer_repo__63__.mdwn new file mode 100644 index 000000000..8e368087f --- /dev/null +++ b/doc/forum/How_to_shrink_transfer_repo__63__.mdwn @@ -0,0 +1,27 @@ +Hello, + +I have two repositories (Asaru and Horus) that are both ```group=client``` and ```wanted=standard```. The other one, Astarte is ```group=transfer``` and ```wanted=standard```. Pretty standard I think. + +``` +repository mode: direct +trusted repositories: 0 +semitrusted repositories: 5 + 00000000-0000-0000-0000-000000000001 -- web + 00000000-0000-0000-0000-000000000002 -- bittorrent + 58001764-966d-4076-ae99-4ef6de25df39 -- Asaru [here] + 8165bdf1-907e-4bbe-9c35-22fbf6f8cb00 -- Astarte [astarte] + cca0c3c8-593a-4395-936c-1093f0f762e8 -- Horus +untrusted repositories: 0 +``` + +I always sync on the two client repos like that ```git annex add . && git annex sync --content```. The transfer repo is growing larger and larger. ```git annex dropunused N``` says, that it ```could only verify the existence of 0 out of 1 necessary copies```. + +What is the best way to clean up the transfer repo? + +1. Make the two client repos trusted? The three repos have been created manually, not through the assistant. Is that what the assistant does, too? +2. Try to get the two client repos into touch with each other and try to use ```dropunsed --from=astarte```? + +What is the recommended way for that? + +Thanks, +Florian diff --git a/doc/forum/Undo_git_merge_git-annex.mdwn b/doc/forum/Undo_git_merge_git-annex.mdwn new file mode 100644 index 000000000..bc299174c --- /dev/null +++ b/doc/forum/Undo_git_merge_git-annex.mdwn @@ -0,0 +1,3 @@ +After accidentally typing git merge git-annex, I am now wondering how to clean up the resulting chaos... + +Any tips? |