Typo fix unncessary -> unnecessary.

Detected while reading recent CHANGELOG entry but then decided to apply
to entire codebase and docs since why not?

doc/bugs/Directory_remotes_with_same_mount_point/comment_4_5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment

@@ -10,6 +10,6 @@ unmounted and remounted for some reason in between the two steps of the
 import would explain the behavior.
 
 Note that I've opened 
-[[todo/import_tree_from_FAT_does_unncessary_work_due_to_inode_instability]]
+[[todo/import_tree_from_FAT_does_unnecessary_work_due_to_inode_instability]]
 after thinking of some other consequences of this.
 """]]

doc/bugs/Git_repos_corrupt_themselves/comment_16_586e591a1e3cc53fd0108da91492c5c2._comment

@@ -15,5 +15,5 @@ Fixed that. Which leaves 2 open questions:
 
 Although the answer to the second question doesn't matter much if the
 data loss bug is fixed -- if there's a problem of some kind causing
-unncessary repairs, it would only be some excess CPU load.
+unnecessary repairs, it would only be some excess CPU load.
 """]]

doc/bugs/Git_repos_corrupt_themselves/comment_18_238bbbcabd626c33acc14f930a7d536c._comment

@@ -6,7 +6,7 @@
 If the assistant crashed in the middle of a repair that confirms my
 analysis, and my fix will avoid both the data loss problem *and* the crash.
 
-Only remaining question to me is why would it trigger an unncessary repair.
+Only remaining question to me is why would it trigger an unnecessary repair.
 
 But that could be anything that causes git fsck to exit nonzero. Or it
 might be that git fsck found an actual problem, but not one that was

doc/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_6_3947b44c88820da49d8a2d1afd3595ff._comment

@@ -8,5 +8,5 @@ more times than necessary. Also was able to avoid updating the git-annex
 branch, which eliminates several calls to git (depending on the number of
 remotes). On Linux, this made it 25% faster. Might be more on Windows.
 
-Rest of the strace looks clean, nothing else stands out as unncessary.
+Rest of the strace looks clean, nothing else stands out as unnecessary.
 """]]

doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment

@@ -15,7 +15,7 @@ files it received to other remotes, and to do that it needs to check if
 their content is present. Which is normally inexpensive, so not a problem.
 
 It so happens that sync calls inAnnex even when
-there are no other remotes to send the content to. Which is unncessary, and
+there are no other remotes to send the content to. Which is unnecessary, and
 avoiding that could be used to fix this problem. But there would still be a
 problem if there were some other remote that the content ought to be sent to,
 if it still called inAnnex in that case. Maybe it's possible to avoid it calling

doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_3_a9b3e07f180ab97f5025d7ce9ca58c05._comment

@@ -14,5 +14,5 @@ the timestamps of anything in the git repo.
 
 Now, if Android is varying the mtime it reports for files, so resulting in
 a changed CID, it may be that would cause an import of content it had already 
-imported before, and maybe that leads to the unncessary commit.
+imported before, and maybe that leads to the unnecessary commit.
 """]]

doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment

@@ -11,7 +11,7 @@ Essentially the same problem as
 (And also the main problem using git-annex on Windows in WSL.)
 
 Not a great deal I can do about this, because the locking is in sqlite.
-That other bug has some thoughts about avoiding unncessary use of sqlite
+That other bug has some thoughts about avoiding unnecessary use of sqlite
 or moving the databases to some other filesystem.
 
 It may be that not enabling WAL mode on the database would change sqlite's

doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment

@@ -3,7 +3,7 @@
  subject="""comment 2"""
  date="2020-06-11T19:26:05Z"
  content="""
-This does seem to be an unncessary use of the database,
+This does seem to be an unnecessary use of the database,
 git-annex init always creates the db in scanUnlockedFiles
 when the repo has a HEAD ref, but normally it will find no unlocked files
 and so it could just not create the database there.

doc/bugs/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn

@@ -95,4 +95,4 @@ Besides reporting the issue, I also have a question:  could I just rerun `export
 [[!meta author=yoh]]
 [[!tag projects/datalad]]
 
-> [[fixed|done]] bypassed this unncessary locking for exports. --[[Joey]]
+> [[fixed|done]] bypassed this unnecessary locking for exports. --[[Joey]]

doc/bugs/get_-J8_on_OSX_leads_to_git-annex__58___git__58___createProcess__58___runInteractiveProcess__58___pipe__58___resource_exhausted___40__Too_many_open_files__41__/comment_9_5db907d77c5f5490c1bdc8e51387a9e9._comment

@@ -23,5 +23,5 @@ Thinking about this over the weekend, I had two ideas:
   Seems likely that only 2 or 3 in the cat-file pool will
   maximise concurrency, because it's not a major bottleneck most of the
   time, and when it is the actual bottleneck is probably disk IO and so
-  won't be helped by more (and likely more only increase unncessary seeks).
+  won't be helped by more (and likely more only increase unnecessary seeks).
 """]]

doc/bugs/git_keeps_refreshing_index/comment_3_919fb06b3fc7fe9b54797a805873e3c8._comment

@@ -20,7 +20,7 @@ so it re-smudges the work tree file unncessarily.
 I have not been able to find a number of files to drop that replicates
 the bug report. When a lot of files are dropped, it starts taking
 sufficiently long to update the index file that it ends up with a newer
-timestamp, which avoids the unncessary additional smudging. The worse
+timestamp, which avoids the unnecessary additional smudging. The worse
 case I have found here is dropping 9 files causes all 9 to get re-smudged,
 but that's not enough to get git to use the progress display.
 """]]

doc/bugs/git_keeps_refreshing_index/comment_4_b73f9c5603bc69867e1619d871a8abb7._comment

@@ -5,7 +5,7 @@
  content="""
 Anyway, if git-annex could preserve the mtime of an unlocked file when
 writing its pointer file or when populating it with content, that would
-avoid the unncessary smudging. (Which seems better than adding a delay when
+avoid the unnecessary smudging. (Which seems better than adding a delay when
 updating the index file, or setting the index's mtime ahead of the current
 time..)
 
@@ -14,6 +14,6 @@ with annex.thin the content is a hard link and it would probably not be
 good to change its mtime.
 
 For now, I didn't do it extensively, but only in depopulatePointerFile.
-That was enough to eliminate the unncessary smudging after drop that I was
+That was enough to eliminate the unnecessary smudging after drop that I was
 seeing.
 """]]

doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn

@@ -4,7 +4,7 @@ When annex.numcopies is 4, and there are only 4 copies of a file,
 	drop me (locking a2...) (locking a3...) (locking a4...) (unsafe)
 	  Could only verify the existence of 3 out of 4 necessary copies
 
-That is unncessary work, because the drop cannot possibly succeed when
+That is unnecessary work, because the drop cannot possibly succeed when
 there are not more than numcopies. It should be able to skip locking the
 content on remotes and immediately fail.