diff options
Diffstat (limited to 'doc/bugs')
13 files changed, 17 insertions, 17 deletions
diff --git a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn b/doc/bugs/20151116_tests_fail_on_OS_X.mdwn index 17b66bbab..fcd32f9dc 100644 --- a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn +++ b/doc/bugs/20151116_tests_fail_on_OS_X.mdwn @@ -33,7 +33,7 @@ FAIL (0.29s) addurl failed on file:///private/var/folders/4j/br7bdhjx4b384_snb2087gt00000gn/T/nix-build-git-annex-5.20151116.drv-0/git-annex-5.20151116/.t/tmprepo0/myurl 2 out of 150 tests failed (126.13s) - (This could be due to a bug in git-annex, or an incompatability + (This could be due to a bug in git-annex, or an incompatibility with utilities, such as git, installed on this system.) ``` diff --git a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn index 9532d0fd0..b0bf84a60 100644 --- a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn +++ b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn @@ -1,6 +1,6 @@ Hi, -some time ago, I accidentially copied some files from the archive to the non-archive part of my (indirect, type 'client') repository (instead of moving), with the effect that assistant always kept downloading and afterwards immediately dropping the files. Now this was not really suprising once I found the duplicate folder, but maybe git annex could detect this case and refuse to run in circles or at least complain about it. +some time ago, I accidentally copied some files from the archive to the non-archive part of my (indirect, type 'client') repository (instead of moving), with the effect that assistant always kept downloading and afterwards immediately dropping the files. Now this was not really surprising once I found the duplicate folder, but maybe git annex could detect this case and refuse to run in circles or at least complain about it. Best Karsten diff --git a/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment b/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment index 43b37c020..90491e562 100644 --- a/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment +++ b/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment @@ -18,10 +18,10 @@ content of objects when in sharedRepository mode, like it normally does. Since that's a belt and suspenders protection, and since the object directory permissions weakening already lost a similar protection against -accidential deletion of object files, shrug, I guess we'll do that. +accidental deletion of object files, shrug, I guess we'll do that. I do feel that sharedRepository mode rarely ever makes sense to use. It's -very fiddely to get the permissions set up right and keep them right, and +very fiddly to get the permissions set up right and keep them right, and there are much better ways to share a centralized repo between users, eg use gitolite or a dedicated account that's locked down to only let git/git-annex commands be run. diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment index 83a01311c..4dfe0f460 100644 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment +++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment @@ -11,8 +11,8 @@ building all libraries again. So, it would be a lot of CPU on an ongoing basis, or a source of unfixed security bugs. And, I think it would not be entirely non-fragile. It's not exactly unheard -of for a new version of a haskell library to accidentially break -compatability with the old version of ghc which is generally unused in the +of for a new version of a haskell library to accidentally break +compatibility with the old version of ghc which is generally unused in the haskell community outside of debian stable. Or, to need a newer version of some C library headers than is in stable, or ... """]] diff --git a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn index d7a635d3c..11f4a9a3e 100644 --- a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn +++ b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn @@ -70,7 +70,7 @@ OK (0.78s) [Removed 1667 lines] 3 out of 269 tests failed (640.58s) - (This could be due to a bug in git-annex, or an incompatability + (This could be due to a bug in git-annex, or an incompatibility with utilities, such as git, installed on this system.) $ diff --git a/doc/bugs/Windows_build_test_failures.mdwn b/doc/bugs/Windows_build_test_failures.mdwn index ac4dce13c..c276c294e 100644 --- a/doc/bugs/Windows_build_test_failures.mdwn +++ b/doc/bugs/Windows_build_test_failures.mdwn @@ -1222,7 +1222,7 @@ crypto preferred content ---------------------------------------------------------------------- Some tests failed! - (This could be due to a bug in git-annex, or an incompatability + (This could be due to a bug in git-annex, or an incompatibility with utilities, such as git, installed on this system.) diff --git a/doc/bugs/addurl_unittest_failing_under_windows.mdwn b/doc/bugs/addurl_unittest_failing_under_windows.mdwn index f1cc7a3a7..8458ed83b 100644 --- a/doc/bugs/addurl_unittest_failing_under_windows.mdwn +++ b/doc/bugs/addurl_unittest_failing_under_windows.mdwn @@ -47,7 +47,7 @@ FAIL (7.16s) addurl failed on file:///Users/born/.t/tmprepo0/myurl 1 out of 1 tests failed (28.13s) - (This could be due to a bug in git-annex, or an incompatability + (This could be due to a bug in git-annex, or an incompatibility with utilities, such as git, installed on this system.) """]] diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn index 0d7804a43..cb0ed5edf 100644 --- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn +++ b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn @@ -10,7 +10,7 @@ I use git v1.9.1 on Ubuntu 14.04 LTS, and git-annex version: 5.20150406-gb2814bc OK, in all honesty, I did a 'git annex sync' between the 'add' and the 'commit' above. But I synced with a clone of the repository that I keep on an external drive, which is less updated than my laptop. It is less updated because I always add content on my laptop and then sync/get from the external disk. So the sync did no harm, apparently. -> Since this seems to be only a problem with messaging about accidentially +> Since this seems to be only a problem with messaging about accidentally > marked dead repositories, I've made fsck mention when a file is only > located in a dead repo, and I've made info tell when it's run in a > supposedly-dead repo. [[done]] --[[Joey]] diff --git a/doc/bugs/direct_mode_merge_interrupt.mdwn b/doc/bugs/direct_mode_merge_interrupt.mdwn index 5c26e1773..f6bb795b6 100644 --- a/doc/bugs/direct_mode_merge_interrupt.mdwn +++ b/doc/bugs/direct_mode_merge_interrupt.mdwn @@ -20,7 +20,7 @@ update the whole work tree, and only after it's updated should it update the index and the current branch to reflect the merge. This way, if the merge is interrupted, the work tree may have uncommitted -changed -- but it's fine if they get accidentially committed, since when +changed -- but it's fine if they get accidentally committed, since when the merge is re-done, those changes will by the same ones made by the merge. (I assume this is how `git merge` normally works.) --[[Joey]] diff --git a/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment b/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment index d97f66d8d..b48cfbca3 100644 --- a/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment +++ b/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment @@ -4,7 +4,7 @@ date="2015-09-09T21:12:01Z" content=""" git-annex should work ok with gpg version 2; there was one minor -incompatability vs gpg version 1, but it was ironed out in 2013. +incompatibility vs gpg version 1, but it was ironed out in 2013. If you build it from source, and have only gpg2 in PATH, and not gpg, it will build a git-annex that runs gpg2. diff --git a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn b/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn index 57c1e1d25..c660f065b 100644 --- a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn +++ b/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn @@ -1,6 +1,6 @@ ### Please describe the problem. -The shim for the standalone version of git annex invokes the dynamic linker with --library-path set appropriatly. glibc's parsing of library-path treats : and ; as seperaters and has no quoting syntax for those characters. Also path items have to be absolute paths so you can't avoid having the whole path. +The shim for the standalone version of git annex invokes the dynamic linker with --library-path set appropriately. glibc's parsing of library-path treats : and ; as separators and has no quoting syntax for those characters. Also path items have to be absolute paths so you can't avoid having the whole path. As a result if you install the standalone version in a directory whose path includes either of those characters it will produce a library-path that's interpreted incorrectly leading to it looking for the libraries in the wrong place and potentially eventually using the system's installed versions if they are available. @@ -18,7 +18,7 @@ This bug applies to any version. with a ':' it will probably occur on any unix, ### Please provide any additional information below. -This bug can't be fixed. It's unlikely to trip people up but might with a bad combination of label-based drive mounting and odd drive labels. The worst case would be incompatable libraries on the system install which could lead to data corruption. +This bug can't be fixed. It's unlikely to trip people up but might with a bad combination of label-based drive mounting and odd drive labels. The worst case would be incompatible libraries on the system install which could lead to data corruption. I recommend that the git annex shim should check for ':' or ';' in the path and exit non-zero if they are found. diff --git a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment index ea9db7bc6..672a3a560 100644 --- a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment +++ b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment @@ -8,7 +8,7 @@ that the other side fails to deal with. We can see in your log that the two rsync are communicating successfully over the ssh connection at first. -This could be something not clean about your ssh connection, or some incompatability +This could be something not clean about your ssh connection, or some incompatibility in the versions of rsync or git-annex between the client and the server. It probably wouldn't hurt to make sure client and server have the same rsync version, and perhaps upgrade them both to the newest git-annex in case this diff --git a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn index ffad58ec8..065ff3ce0 100644 --- a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn +++ b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn @@ -1,8 +1,8 @@ ### Please describe the problem. -I understand that `git annex unannex` is essentially there for undoing an accidential `git annex add`. Unfortunately it doesn't do that. +I understand that `git annex unannex` is essentially there for undoing an accidental `git annex add`. Unfortunately it doesn't do that. -If I have uncommited changes, which is the case after a `git annex add`, it tells me: +If I have uncommitted changes, which is the case after a `git annex add`, it tells me: git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit CallStack (from HasCallStack): |