diff options
author | 2017-02-11 09:38:49 +0000 | |
---|---|---|
committer | 2017-02-12 17:30:23 -0400 | |
commit | c6e4dcca673841f29449c8c2bf85fa41b31da12f (patch) | |
tree | a0e16f9c52f6690be527044031607d97fae7d706 /doc | |
parent | f765752568381ca2f003c08e9601fb2b5c397b5b (diff) |
correct spelling mistakes
Diffstat (limited to 'doc')
40 files changed, 51 insertions, 51 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): diff --git a/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn b/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn index 78d263b6d..0dd600cc8 100644 --- a/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn +++ b/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn @@ -13,7 +13,7 @@ at debugging output to find: messages. 2. The git-receive-pack side waited on the wrong thread, so didn't notice when the program was done. -3. I accidentially used the wrong attribute name when sending a ReceivePackDone +3. I accidentally used the wrong attribute name when sending a ReceivePackDone message. But all in all, it just worked. diff --git a/doc/design/assistant/blog/day_172__short_day.mdwn b/doc/design/assistant/blog/day_172__short_day.mdwn index 031f90e0f..80a32d87e 100644 --- a/doc/design/assistant/blog/day_172__short_day.mdwn +++ b/doc/design/assistant/blog/day_172__short_day.mdwn @@ -1,5 +1,5 @@ Only one bug fix today, but it was a doozie. It seems that gpg2 has an -incompatability with the gpg 1.x that git-annex was written for, that +incompatibility with the gpg 1.x that git-annex was written for, that causes large numbers of excess passphrase prompts, when it's supposed to be using a remote's symmetric encryption key. Adding the --batch parameter fixed this. diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment index 57a601530..455029a41 100644 --- a/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment +++ b/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment @@ -6,5 +6,5 @@ content=""" @Karsten does KBOX work on this version of Android? <http://kevinboone.net/Term-debug.apk> -It may well be that this is just too old and incompatable for the terminal to work. +It may well be that this is just too old and incompatible for the terminal to work. """]] diff --git a/doc/design/assistant/upgrading.mdwn b/doc/design/assistant/upgrading.mdwn index b1d658c8b..1395d0cd8 100644 --- a/doc/design/assistant/upgrading.mdwn +++ b/doc/design/assistant/upgrading.mdwn @@ -21,7 +21,7 @@ restarts itself. To clean up the old installation, a git-annex.MANIFEST file is looked for in it, and the files listed, as well as empty directories, are deleted. -I don't want to accidentially delete something I didn't ship! +I don't want to accidentally delete something I didn't ship! ## restart on upgrade diff --git a/doc/design/caching_database.mdwn b/doc/design/caching_database.mdwn index 87efd9810..c27c9557c 100644 --- a/doc/design/caching_database.mdwn +++ b/doc/design/caching_database.mdwn @@ -87,7 +87,7 @@ MVars.) (Note that if the database is a cache, there is no need to perform migrations when querying it. My benchmarks skip `runMigration`. Instead, if the query -fails, the database doesn't exist, or uses an incompatable schema, and the +fails, the database doesn't exist, or uses an incompatible schema, and the cache can be rebuilt then. This avoids the problem that persistent's migrations can sometimes fail.) diff --git a/doc/devblog/day_109__elimintating_absNormPath.mdwn b/doc/devblog/day_109__elimintating_absNormPath.mdwn index a15cb7f09..8381f2956 100644 --- a/doc/devblog/day_109__elimintating_absNormPath.mdwn +++ b/doc/devblog/day_109__elimintating_absNormPath.mdwn @@ -11,7 +11,7 @@ That fixed one last Windows bug that was disabled in the test suite: `git annex add ..\subdir\file` will now work. I am re-installing the Android autobuilder for 2 reasons: I noticed I had -accidentially lost a patch to make a library use the Android SSL cert directory, +accidentally lost a patch to make a library use the Android SSL cert directory, and also a new version of GHC is very near to release and so it makes sense to update. diff --git a/doc/devblog/day_248__workload_tuning.mdwn b/doc/devblog/day_248__workload_tuning.mdwn index d1fee2926..d0677fc60 100644 --- a/doc/devblog/day_248__workload_tuning.mdwn +++ b/doc/devblog/day_248__workload_tuning.mdwn @@ -8,7 +8,7 @@ Today I put together a lot of things I've been thinking about: git-annex user to upgrade their repository, and would be very painful. It's hard to imagine a change that is worth that amount of pain. * There are other changes some would like to see (like lower-case object - hash directory names) that are certianly not enough to warrant a flag + hash directory names) that are certainly not enough to warrant a flag day repo format upgrade. * It would be nice to let people who want to have some flexibility to play around with changes, in their own repos, as long as they don't a) @@ -32,7 +32,7 @@ The main limitations are: I built all the infrastructure for this today. Basically, the git-annex branch gets a record of all tunings that have been applied, and they're -automatically propigated to new clones of a repository. +automatically propagated to new clones of a repository. And I implemented the first tunable setting: @@ -40,10 +40,10 @@ And I implemented the first tunable setting: This is definitely an experimental feature for now. `git-annex merge` and similar commands will detect attempts to merge -between incompatably tuned repositories, and error out. But, there are a +between incompatibly tuned repositories, and error out. But, there are a lot of ways to shoot yourself in the foot if you use this feature: -* Nothing stops `git merge` from merging two incompatable repositories. +* Nothing stops `git merge` from merging two incompatible repositories. * Nothing stops any version of git-annex older from today from merging either. diff --git a/doc/devblog/day_280__slow_week.mdwn b/doc/devblog/day_280__slow_week.mdwn index 0c49b33bc..ed0dce49d 100644 --- a/doc/devblog/day_280__slow_week.mdwn +++ b/doc/devblog/day_280__slow_week.mdwn @@ -2,7 +2,7 @@ Reduced activity this week (didn't work on the assistant after all), but several things got done: Monday: Fixed `fsck --fast --from remote` to not fail when the remote -didn't support fast copy mode. And dealt with an incompatability in S3 bucket +didn't support fast copy mode. And dealt with an incompatibility in S3 bucket names; the old hS3 library supported upper-case bucket names but the new one needs them all in lower case. diff --git a/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn b/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn index 58755de91..d55823f75 100644 --- a/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn +++ b/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn @@ -14,8 +14,8 @@ and so lets a lot of queries be done much faster. The implementation should make it easy to add --batch to more plumbing commands as needed, and could probably extend to non-plumbing commands too. -Today: The first 5 hours involved an incompatable mess of ssh and rsync -versions on Windows. A gordian knot of brokenness and depedency hell. +Today: The first 5 hours involved an incompatible mess of ssh and rsync +versions on Windows. A Gordian knot of brokenness and dependency hell. I finally found a solution which involves downgrading the cygwin rsync to an older version, and using msysgit's ssh rather than cygwin's. diff --git a/doc/devblog/day_307__two_release_week.mdwn b/doc/devblog/day_307__two_release_week.mdwn index 32202906f..0b8a1595e 100644 --- a/doc/devblog/day_307__two_release_week.mdwn +++ b/doc/devblog/day_307__two_release_week.mdwn @@ -1,5 +1,5 @@ Made a release this morning, mostly because the release earlier this week -turns out to have accidentially removed several options from `git annex copy`. +turns out to have accidentally removed several options from `git annex copy`. Spent some time this afternoon improving how git-annex shuts down when --time-limit is used. This used to be a quick and dirty shutdown, similar diff --git a/doc/devblog/day_35__anacron_and_bugfixing.mdwn b/doc/devblog/day_35__anacron_and_bugfixing.mdwn index af021d576..dc8fbb628 100644 --- a/doc/devblog/day_35__anacron_and_bugfixing.mdwn +++ b/doc/devblog/day_35__anacron_and_bugfixing.mdwn @@ -3,13 +3,13 @@ one more feature to it today: Full anacron style scheduling. So a fsck can be scheduled to run once per week, or month, or year, and it'll run the fsck the next time it's available after that much time has passed. The nice thing about this is I didn't have to change Cronner *at all* to add this, -just improved the Recurrance data type and the code that calculates when +just improved the Recurrence data type and the code that calculates when to run events. Rest of the day I've been catching up on some bug reports. The main bug I fixed caused git-annex on Android to hang when adding files. This turns out to be because it's using a new (unreleased) version of git, and -`git check-attr -z` output format has changed in an incompatable way. +`git check-attr -z` output format has changed in an incompatible way. I am currently 70 messages behind, which includes some ugly looking bug reports, so I will probably continue with this over the next couple days. diff --git a/doc/devblog/day_387__release_day.mdwn b/doc/devblog/day_387__release_day.mdwn index 0a36a61da..c7a294aed 100644 --- a/doc/devblog/day_387__release_day.mdwn +++ b/doc/devblog/day_387__release_day.mdwn @@ -1,6 +1,6 @@ git-annex 6.20160419 has a rare security fix. A [bug](http://git-annex.branchable.com/bugs/External_special_remote_broken__63__/) made encrypted special -remotes that are configured to use chunks accidentially expose the checksums +remotes that are configured to use chunks accidentally expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption. The same bug also made resuming interrupted uploads to such remotes start over from the beginning. diff --git a/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment b/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment index f345e64b7..9c20baad7 100644 --- a/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment +++ b/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment @@ -4,7 +4,7 @@ subject="comment 1" date="2016-04-29T10:26:22Z" content=""" -> A bug made encrypted special remotes that are configured to use chunks accidentially expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption. +> A bug made encrypted special remotes that are configured to use chunks accidentally expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption. What should the users do to repair this situation? How can the exposed checksums be removed from the remote? Is a `git annex sync` enough? diff --git a/doc/devblog/day_396__misc_fixes.mdwn b/doc/devblog/day_396__misc_fixes.mdwn index ed9219adf..8f33d66ea 100644 --- a/doc/devblog/day_396__misc_fixes.mdwn +++ b/doc/devblog/day_396__misc_fixes.mdwn @@ -1,5 +1,5 @@ A productive day of small fixes. Including a change to deal with an -incompatability in git 2.9's commit.gpgsign, and couple of fixes +incompatibility in git 2.9's commit.gpgsign, and couple of fixes involving gcrypt repositories. Also several improvements to cloning from repositories where an adjusted diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment index f3a1ca577..cadf944cd 100644 --- a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment +++ b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment @@ -6,7 +6,7 @@ content=""" \"Checking out files\" is a message printed by git (not by git-annex) when it is updating the work tree. -It still seems that you have somehow committed large files directly to git. Perhaps you accidentially ran \"git add\" on a large file. +It still seems that you have somehow committed large files directly to git. Perhaps you accidentally ran \"git add\" on a large file. git annex sync is probably merging this commit from one of your other repositories. """]] diff --git a/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment index 6cf5541e8..9cbe0939c 100644 --- a/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment +++ b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment @@ -9,7 +9,7 @@ A few likely reasons: * If a 4th client repository had popped up. * If you have configured a high number of copies, it might only be able to be met by keeping files on the transfer repository. * Similarly, if a repository that used to have the files has been marked as dead or deleted, more copies might be needed to make up for that. -* For completeness, if the transfer repository accidentially had its type changed to some other kind of repository, like a full backup. +* For completeness, if the transfer repository accidentally had its type changed to some other kind of repository, like a full backup. You can enable debugging (start with --debug or go into the webapp's preferences) and it might say a little more, but the debugging info is not very good. diff --git a/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment b/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment index f762c0445..05dbbed76 100644 --- a/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment +++ b/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment @@ -16,5 +16,5 @@ too many files to look at. Another approach is to look at the git log, find the commit that merged the unwanted changed (and created these variant files), and `git revert` that -merge, and the earlier commit that was made accidentially. +merge, and the earlier commit that was made accidentally. """]] diff --git a/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment index c30ad8999..46ddb5f16 100644 --- a/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment +++ b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment @@ -3,7 +3,7 @@ subject="""comment 2""" date="2015-09-09T18:18:17Z" content=""" -I wish this incompatability didn't exist either, but the transition to use +I wish this incompatibility didn't exist either, but the transition to use consistently 3 letter hash directories would be too much to ask of all the users. And there are ways to convert a bare to non-bare that don't have this problem, like making a clone and using `git annex move --all --from diff --git a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment index 4b250a3e2..d0b89c59e 100644 --- a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment +++ b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment @@ -26,5 +26,5 @@ And here for a binary file stored in git: If you find the latter in the log, then the author and commit message of the commit adding it would be interesting. -Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentially committed it directly to git. +Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentally committed it directly to git. """]] diff --git a/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment b/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment index 3a07bf0af..d2f3c4f73 100644 --- a/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment +++ b/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment @@ -7,8 +7,8 @@ From the man page: > Until a repository (**or one of its remotes**) has been initialized -> git-annex will refuse to operate on it, to avoid accidentially -> using it in a repository that was not intended tohave an annex. +> git-annex will refuse to operate on it, to avoid accidentally +> using it in a repository that was not intended to have an annex. So, yes, it assumes that if a repository has a git-annex branch already, git-annex is being used, and no explicit init is necessary. You can still run `git annex init` after the fact if you like. """]] diff --git a/doc/forum/webapp_does_not_start.mdwn b/doc/forum/webapp_does_not_start.mdwn index 3003af7d0..ad4275970 100644 --- a/doc/forum/webapp_does_not_start.mdwn +++ b/doc/forum/webapp_does_not_start.mdwn @@ -42,7 +42,7 @@ EDIT: Exception: .t/tmprepo9/.git/annex/journal: getDirectoryContents: permission denied (Access is denied.) 2 out of 83 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/internals/lockdown.mdwn b/doc/internals/lockdown.mdwn index a7775cd3a..5e1160de1 100644 --- a/doc/internals/lockdown.mdwn +++ b/doc/internals/lockdown.mdwn @@ -1,6 +1,6 @@ Object files stored in `.git/annex/objects` are each put in their own directory. This allows the write bit to be removed from both the file, and its directory, -which prevents accidentially deleting or changing the file contents. +which prevents accidentally deleting or changing the file contents. The reasoning for doing this follows: @@ -16,7 +16,7 @@ But git-annex does not make a local copy of a file added to it, because the file could be very large. So, it's important for git-annex to find another way to preserve the expected -property that once committed, you cannot accidentially lose a file. +property that once committed, you cannot accidentally lose a file. The most important protection it makes is just to remove the write bit of the file. Thus preventing programs from modifying it. diff --git a/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment b/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment index 47b0aaefa..f29a2e34c 100644 --- a/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment +++ b/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment @@ -4,5 +4,5 @@ subject="comment 12" date="2013-05-24T15:33:12Z" content=""" -Ah -- No, your AWS creds are not stored. While some other special remotes, like webdav, can store all necessary credentials, it's not done for AWS. I didn't want git-annex to be responsible for someone accidentially publishing their AWS creds to their friends, since that could cost them a lot of money. +Ah -- No, your AWS creds are not stored. While some other special remotes, like webdav, can store all necessary credentials, it's not done for AWS. I didn't want git-annex to be responsible for someone accidentally publishing their AWS creds to their friends, since that could cost them a lot of money. """]] diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn b/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn index 354469118..2df15f193 100644 --- a/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn +++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn @@ -48,7 +48,7 @@ data out of your encrypted backup. You need to find a secure way to store a backup of your gpg key. Printing it out and storing it in a safe deposit box, for example. -You can actually specifiy keyid= as many times as you like to allow any one +You can actually specify keyid= as many times as you like to allow any one of a set of gpg keys to access this repository. So you could add a friend's key, or another gpg key you have. diff --git a/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment b/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment index ca60ec5fd..0732b7dde 100644 --- a/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment +++ b/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment @@ -6,7 +6,7 @@ Restarting the daemon should just take a second and the web browser should redirect to the new instance. I guess it does move away from the current page to the dashboard, and in a way that the back button can't undo, but I -see no other harm in accidentially restarting the daemon. +see no other harm in accidentally restarting the daemon. So, I think I'll just add a spacer to separate the repository part of that menu from the daemon part. diff --git a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment index ba8526a34..6d4f9b026 100644 --- a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment +++ b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment @@ -10,7 +10,7 @@ out of the user's view, because it's a complication that should not need to worry about. Keeping it in an env var does avoid complicating the discoverable -interface with some parameter to specifiy the commit message. Another +interface with some parameter to specify the commit message. Another way would be to make the commit message configurable in git config. Then it could be overridden with -c. Seems like the user of this feature is likely going to also use annex.alwayscommit=false sometimes diff --git a/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment b/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment index 8e955fd48..2907dafc3 100644 --- a/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment +++ b/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment @@ -4,7 +4,7 @@ subject="comment 3" date="2012-11-04T19:58:28Z" content=""" -I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentially git committing a bad symlink. Or the user accidentially doing something with a partially transferred file. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.) +I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentally git committing a bad symlink. Or the user accidentally doing something with a partially transferred file. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.) However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`. """]] |