Typo fix unncessary -> unnecessary.

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

Annex/AdjustedBranch/Merge.hs

@@ -54,7 +54,7 @@ mergeToAdjustedBranch tomerge (origbranch, adj) mergeconfig canresolvemerge comm
 	nochangestomerge = return $ return True
 
 	{- Since the adjusted branch changes files, merging tomerge
-	 - directly into it would likely result in unncessary merge
+	 - directly into it would likely result in unnecessary merge
 	 - conflicts. To avoid those conflicts, instead merge tomerge into
 	 - updatedorig. The result of the merge can the be
 	 - adjusted to yield the final adjusted branch.

Annex/Content/PointerFile.hs

@@ -62,7 +62,7 @@ depopulatePointerFile key file = do
 		let tmp' = toRawFilePath tmp
 		liftIO $ writePointerFile tmp' key mode
 #if ! defined(mingw32_HOST_OS)
-		-- Don't advance mtime; this avoids unncessary re-smudging
+		-- Don't advance mtime; this avoids unnecessary re-smudging
 		-- by git in some cases.
 		liftIO $ maybe noop
 			(\t -> touch tmp' t False)

CHANGELOG

@@ -4,7 +4,7 @@ git-annex (10.20220725) UNRELEASED; urgency=medium
     automatically upgrade to v10 in a year's time.
     To avoid this upgrade, you can set annex.autoupgraderepository to false.
   * Use v10 by default for new repositories.
-  * Avoid starting an unncessary number of git hash-object processes when 
+  * Avoid starting an unnecessary number of git hash-object processes when 
     concurrency is enabled.
   * stack.yaml: Updated to lts-19.16
   * Added new matching options --want-get-by and --want-drop-by.
@@ -411,7 +411,7 @@ git-annex (8.20210803) upstream; urgency=medium
 
 git-annex (8.20210714) upstream; urgency=medium
 
-  * assistant: Avoid unncessary git repository repair in a situation where
+  * assistant: Avoid unnecessary git repository repair in a situation where
     git fsck gets confused about a commit that is made while it's running.
   * addurl: Avoid crashing when used on beegfs.
   * --debug output goes to stderr again, not stdout.
@@ -652,7 +652,7 @@ git-annex (8.20210127) upstream; urgency=medium
     Thanks, Grond for the patch.
   * Avoid crashing when there are remotes using unparseable urls.
     Including the non-standard URI form that git-remote-gcrypt uses for rsync.
-  * Directory special remotes with importtree=yes now avoid unncessary
+  * Directory special remotes with importtree=yes now avoid unnecessary
     hashing when inodes of files have changed, as happens whenever a FAT
     filesystem gets remounted.
   * Fix a bug that prevented git-annex init from working in a submodule.
@@ -2359,7 +2359,7 @@ git-annex (6.20180112) upstream; urgency=medium
     remotes, which used to cause eg, spin-up of removable drives.
   * Added remote.<name>.annex-checkuuid config, which can be set to false
     to disable the default checking of the uuid of remotes that point to
-    directories. This can be useful to avoid unncessary drive spin-ups and
+    directories. This can be useful to avoid unnecessary drive spin-ups and
     automounting.
   * git-annex.cabal: Add back custom-setup stanza, so cabal new-build works.
   * git-annex.cabal: Removed the testsuite build flag; test suite is always
@@ -2623,7 +2623,7 @@ git-annex (6.20170510) unstable; urgency=medium
   * version: Added "dependency versions" line.
   * Keys marked as dead are now skipped by --all.
   * annex.backend is the new name for what was annex.backends, and takes
-    a single key-value backend, rather than the unncessary and confusing
+    a single key-value backend, rather than the unnecessary and confusing
     list. The old option still works if set.
 
  -- Joey Hess <id@joeyh.name>  Wed, 10 May 2017 15:05:22 -0400
@@ -2901,7 +2901,7 @@ git-annex (6.20161111) unstable; urgency=medium
   * S3: Support the special case endpoint needed for the cn-north-1 region.
   * Webapp: Don't list the Frankfurt S3 region, as this (and some other new
     regions) need V4 authorization which the aws library does not yet use.
-  * reinject --known: Avoid second, unncessary checksum of file.
+  * reinject --known: Avoid second, unnecessary checksum of file.
   * OSX: Remove RPATHs from git-annex binary, which are not needed,
     slow down startup, and break the OSX Sierra linker.
   * webapp: Explicitly avoid checking for auth in static subsite
@@ -2982,7 +2982,7 @@ git-annex (6.20160923) unstable; urgency=medium
 
   * Rate limit console progress display updates to 10 per second.
     Was updating as frequently as changes were reported, up to hundreds of
-    times per second, which used unncessary bandwidth when running git-annex
+    times per second, which used unnecessary bandwidth when running git-annex
     over ssh etc.
   * Make --json and --quiet work when used with -J.
     Previously, -J override the other options.
@@ -3639,7 +3639,7 @@ git-annex (5.20151019) unstable; urgency=medium
   * copy --auto was checking the wrong repo's preferred content.
     (--from was checking what --to should, and vice-versa.)
     Fixed this bug, which was introduced in version 5.20150727.
-  * Avoid unncessary write to the location log when a file is unlocked
+  * Avoid unnecessary write to the location log when a file is unlocked
     and then added back with unchanged content.
   * S3: Fix support for using https.
   * Avoid displaying network transport warning when a ssh remote
@@ -4580,7 +4580,7 @@ git-annex (5.20140717) unstable; urgency=high
   * sync: Fix git sync with local git remotes even when they don't have an
     annex.uuid set. (The assistant already did so.)
   * Set gcrypt-publish-participants when setting up a gcrypt repository,
-    to avoid unncessary passphrase prompts.
+    to avoid unnecessary passphrase prompts.
     This is a security/usability tradeoff. To avoid exposing the gpg key
     ids who can decrypt the repository, users can unset
     gcrypt-publish-participants.
@@ -4602,7 +4602,7 @@ git-annex (5.20140709) unstable; urgency=medium
   * Fix git version that supported --no-gpg-sign.
   * Fix bug in automatic merge conflict resolution, when one side is an
     annexed symlink, and the other side is a non-annexed symlink.
-  * Really fix bug that caused the assistant to make many unncessary
+  * Really fix bug that caused the assistant to make many unnecessary
     empty merge commits.
 
  -- Joey Hess <joeyh@debian.org>  Wed, 09 Jul 2014 15:28:03 -0400
@@ -4610,7 +4610,7 @@ git-annex (5.20140709) unstable; urgency=medium
 git-annex (5.20140707) unstable; urgency=medium
 
   * assistant: Fix bug, introduced in last release, that caused the assistant
-    to make many unncessary empty merge commits.
+    to make many unnecessary empty merge commits.
   * assistant: Fix one-way assistant->assistant sync in direct mode.
   * Fix bug in annex.queuesize calculation that caused much more
     queue flushing than necessary.
@@ -4738,7 +4738,7 @@ git-annex (5.20140421) unstable; urgency=medium
     connections.
   * Improve handling of monthly/yearly scheduling.
   * Avoid depending on shakespeare except for when building the webapp.
-  * uninit: Avoid making unncessary copies of files.
+  * uninit: Avoid making unnecessary copies of files.
   * info: Allow use in a repository where annex.uuid is not set.
   * reinit: New command that can initialize a new repository using
     the configuration of a previously known repository.
@@ -5573,7 +5573,7 @@ git-annex (4.20130802) unstable; urgency=low
   * importfeed can be used to import files from podcast feeds.
   * webapp: When setting up a dedicated ssh key to access the annex
     on a host, set IdentitiesOnly to prevent the ssh-agent from forcing
-    use of a different ssh key. That could result in unncessary password
+    use of a different ssh key. That could result in unnecessary password
     prompts, or prevent git-annex-shell from being run on the remote host.
   * webapp: Improve handling of remotes whose setup has stalled.
   * Add status message to XMPP presence tag, to identify to others that
@@ -5748,7 +5748,7 @@ git-annex (4.20130621) unstable; urgency=low
 git-annex (4.20130601) unstable; urgency=medium
 
   * XMPP: Git push over xmpp made much more robust.
-  * XMPP: Avoid redundant and unncessary pushes. Note that this breaks
+  * XMPP: Avoid redundant and unnecessary pushes. Note that this breaks
     compatibility with previous versions of git-annex, which will refuse
     to accept any XMPP pushes from this version.
   * XMPP: Send pings and use them to detect when contact with the server
@@ -6066,7 +6066,7 @@ git-annex (4.20130314) unstable; urgency=low
     combines all their changes into a single commit.
   * assistant: Fix ~/.ssh/git-annex-shell wrapper to work when the
     ssh key does not force a command.
-  * assistant: Be smarter about avoiding unncessary transfers.
+  * assistant: Be smarter about avoiding unnecessary transfers.
 
   * webapp: Work around bug in Warp's slowloris attack prevention code,
     that caused regular browsers to stall when they reuse a connection

Database/Keys.hs

@@ -226,7 +226,7 @@ isInodeKnown i s = or <$> runReaderIO ((:[]) <$$> SQL.isInodeKnown i s)
  - This is run with a lock held, so only one process can be running this at
  - a time.
  -
- - To avoid unncessary work, the index file is statted, and if it's not
+ - To avoid unnecessary work, the index file is statted, and if it's not
  - changed since last time this was run, nothing is done.
  -
  - A tree is generated from the index, and the diff between that tree

Database/Keys/SQL.hs

@@ -140,7 +140,7 @@ isInodeKnown i s = readDb (isJust <$> selectFirst q [])
 		| sentinalInodesChanged s =
 			-- Note that this select is intentionally not
 			-- indexed. Normally, the inodes have not changed,
-			-- and it would be unncessary work to maintain
+			-- and it would be unnecessary work to maintain
 			-- indexes for the unusual case.
 			[ ContentFilesize ==. inodeCacheToFileSize i
 			, ContentMtime >=. tmin

Remote/Borg.hs

@@ -223,7 +223,7 @@ listImportableContentsM u borgrepo c = prompt $ do
 			    (reqsz, retsz) = case extra of
 				" link to " -> (Nothing, fromMaybe sz . fromKey keySize)
 				_ -> (Just sz, const sz)
-			-- This does a little unncessary work to parse the 
+			-- This does a little unnecessary work to parse the 
 			-- key, which is then thrown away. But, it lets the
 			-- file list be shrank down to only the ones that are
 			-- importable keys, so avoids needing to buffer all

Remote/GCrypt.hs

@@ -355,7 +355,7 @@ shellOrRsync r ashell arsync
  -
  - (For shared encryption, gcrypt's default behavior is used.)
  -
- - Also, sets gcrypt-publish-participants to avoid unncessary gpg
+ - Also, sets gcrypt-publish-participants to avoid unnecessary gpg
  - passphrase prompts.
  -}
 setGcryptEncryption :: ParsedRemoteConfig -> String -> Annex ()

Remote/Helper/ExportImport.hs

@@ -143,7 +143,7 @@ adjustExportImport' isexport isimport r rs = do
 			else importUnsupported
 		, storeKey = \k af p ->
 			-- Storing a key on an export could be implemented,
-			-- but it would perform unncessary work
+			-- but it would perform unnecessary work
 			-- when another repository has already stored the
 			-- key, and the local repository does not know
 			-- about it. To avoid unnecessary costs, don't do it.

Types/Key.hs

@@ -71,7 +71,7 @@ data Key = MkKey
 	} deriving (Show, Generic)
 
 instance Eq Key where
-	-- comparing the serialization would be unncessary work
+	-- comparing the serialization would be unnecessary work
 	a == b = keyData a == keyData b
 
 instance Ord Key where

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. 
 

doc/design/assistant/syncing/efficiency.mdwn

@@ -7,7 +7,7 @@ dumb, and potentially inneficient:
 2. After each file transfer (upload or download), a git sync
    is done to all the remotes, to update location log information.
 
-## unncessary transfers
+## unnecessary transfers
 
 There are network toplogies where #1 is massively inneficient.
 For example:
@@ -27,7 +27,7 @@ LAN to laptopC.
 (The more common case with no laptopC happens to work efficiently.
 So does the case where laptopA is paired with laptopC.)
 
-## unncessary syncing
+## unnecessary syncing
 
 Less importantly, the constant git syncing after each transfer is rather a
 lot of work, and prevents collecting multiple presence changes to the git-annex 
@@ -50,7 +50,7 @@ necessary, and defer it.
 ## mapping
 
 Mapping the repository network has the potential to get git-annex the
-information it needs to avoid unnecessary transfers and/or unncessary
+information it needs to avoid unnecessary transfers and/or unnecessary
 syncing.
 
 Mapping the network can reuse code in `git annex map`. Once the map is

doc/devblog/day_378__finishing_adjusted_branches_merge.mdwn

@@ -1,6 +1,6 @@
 Well, I had to rethink how merges into adjusted branches should be handled.
 The old method often led to unnecessary merge conflicts. My new approach
-should always avoid unncessary merge conflicts, but it's quite a trick.
+should always avoid unnecessary merge conflicts, but it's quite a trick.
 
 To merge origin/master into adjusted/master, it first merges origin/master
 into master. But, since adjusted/master is checked out, it has to do the

doc/devblog/day_483__faster_start_with_removable_drives.mdwn

@@ -3,7 +3,7 @@ repository it's running in. That's been optimised some before, but
 not entirely eliminated; it's just too useful to have that information
 always available inside git-annex. But it turned out that it was doing more work
 than needed for many commands, by checking the git config of local remotes.
-Thas caused unncessary spin up of removable drives, or automount timeouts,
+Thas caused unnecessary spin up of removable drives, or automount timeouts,
 or generally more work than needed when running commands like `git annex
 find` and even tab completing git-annex. That's fixed now, so it
 avoids checking the git config of remotes except when running commands that

doc/devblog/day_487__git-annex-shell_p2pstdio.mdwn

@@ -4,7 +4,7 @@ this.
 
 The only complication was that git-annex-shell has a readonly mode,
 so the protocol server needed modifications to support that.
-Well, there's also some innefficiency around unncessary verification
+Well, there's also some innefficiency around unnecessary verification
 of transferred content in some cases, which will probably need extensions
 to the P2P protocol later.
 

doc/devblog/day_570__brrr.mdwn

@@ -11,7 +11,7 @@ I got sidetracked with how S3 prepares a handle to the server. That didn't
 work as well as it might have; most of the time each request to the remote
 actually prepared a new handle, rather than reusing a single handle. Though
 the http connection to the server did get reused, that still caused a lot
-of unncessary work. I fixed that, and the fix also allowed me to
+of unnecessary work. I fixed that, and the fix also allowed me to
 restructure export actions in the way I need for progress bars.
 
 I've ran out of time to finish adding the missing progress bars today, so

doc/forum/Different_preferred_content_for_subdirs/comment_1_5c1e1e6375360cc9416821085b5a68a8._comment

@@ -12,6 +12,6 @@ to apply `not (copies=archive:4)`.
 I am kind of surprised that the original situation would lead to any churn
 though. It seems like, since it knows there are at most 3, copies, and 4
 copies are required, it should be able to skip trying to drop at all.
-Instead it does unncessary work. Filed a bug,
+Instead it does unnecessary work. Filed a bug,
 [[bugs/unnecessary_work_when_drop_cannot_possibly_succeed]].
 """]]

doc/git-annex-adjust.mdwn

@@ -30,7 +30,7 @@ made such as adding/deleting files, but will not propagate the adjustments
 made by this command.
 
 When in an adjusted branch, using `git merge otherbranch` is often not
-ideal, because merging a non-adjusted branch may lead to unncessary
+ideal, because merging a non-adjusted branch may lead to unnecessary
 merge conflicts, or add files in non-adjusted form. To avoid those
 problems, use `git annex merge otherbranch`.
 

doc/git-annex-benchmark.mdwn

@@ -46,7 +46,7 @@ instead of a command. N is the number of items to benchmark.
 
 The output of the commands being benchmarked goes to standard output and
 standard error as usual. It's often a good idea to use --quiet to avoid
-unncessary output, unless the generation of that output is part of what
+unnecessary output, unless the generation of that output is part of what
 you want to benchmark.
 
 The benchmark report is output to standard output by default, although

doc/git-annex-filter-process.mdwn

@@ -16,7 +16,7 @@ annexed files do not make `git checkout` slow, but unlocked files and
 non-annexed files do slow it down.)
 
 On the other hand when this is enabled, `git add` of a large file does an
-unncessary extra read of the file, and pipes its contents into git-annex.
+unnecessary extra read of the file, and pipes its contents into git-annex.
 So when this is enabled, it will be faster to use `git-annex add` to add
 large files to the annex, rather than `git add`. Other commands that
 add files, like `git commit -a`, are also impacted by this.

doc/git-annex.mdwn

@@ -1487,7 +1487,7 @@ Remotes are configured using these settings in `.git/config`.
   Setting annex-checkuuid to false will prevent it from checking the uuid 
   at startup (although the uuid is still verified before making any
   changes to the remote repository). This may be useful to set to prevent
-  unncessary spin-up or automounting of a drive.
+  unnecessary spin-up or automounting of a drive.
 
 * `remote.<name>.annex-trustlevel`
 

doc/special_remotes/gcrypt.mdwn

@@ -60,6 +60,6 @@ be decrypted by the added keys. Probably this can be done by setting
 `GCRYPT_FULL_REPACK` and doing a forced push of branches.
 
 Recent versions of git-annex configure `remote.<name>`gcrypt-publish-participants` when
-setting up a gcrypt repository. This is done to avoid unncessary gpg
+setting up a gcrypt repository. This is done to avoid unnecessary gpg
 passphrase prompts, but it does publish the gpg keyids that can decrypt the
 repository. Unset it if you need to obscure that.

doc/special_remotes/git-lfs.mdwn

@@ -67,7 +67,7 @@ be decrypted by the added keys. Probably this can be done by setting
 `GCRYPT_FULL_REPACK` and doing a forced push of branches.
 
 git-annex will set `remote.<name>`gcrypt-publish-participants` when setting
-up a repository that uses gcrypt. This is done to avoid unncessary gpg
+up a repository that uses gcrypt. This is done to avoid unnecessary gpg
 passphrase prompts, but it does publish the gpg keyids that can decrypt the
 repository. Unset it if you need to obscure that.
 

doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_13_440624874dd3697dd538655765f2b6a2._comment

@@ -3,7 +3,7 @@
  subject="""comment 13"""
  date="2021-05-31T18:40:59Z"
  content="""
-There was an unncessary check of the current time per sql insert, removing
+There was an unnecessary check of the current time per sql insert, removing
 that sped it up by 3 seconds in my benchmark.
 
 Also tried increasing the number of inserts per sqlite transaction from 1k

doc/todo/ditch_yesod.mdwn

@@ -5,7 +5,7 @@ reasons:
   painful for the android port, other builds like debian mips that don't
   currently support TH, etc. (Update: mips does support it now, it seems!)
 * I think it's responsible for at least 50% of the executable size, and I
-  suspect a lot of that is unncessary bloat for parts of yesod that
+  suspect a lot of that is unnecessary bloat for parts of yesod that
   git-annex doesn't really use.
 * Hamlet constantly annoys me by rejecting any file that contains tabs.
   **Rage**

doc/todo/dynamic_stall_detection.mdwn

@@ -9,7 +9,7 @@ flowing, it's almost certainly stalled. And if the progress display is
 updated less frequently, see if it's updated every 2 minutes, etc. Although
 realistically, progress displays are updated every chunk, and there's
 typically more than 1 chunk per minute. So longer durations than 1 minute
-may be an unncessary complication. And a minute to detect a stall is fine.
+may be an unnecessary complication. And a minute to detect a stall is fine.
 
 > Implemented this, annex.stalldetection = true enables automatic.
 

doc/todo/external_backends/comment_8_e3c66820da36fe255d07059226690ca4._comment

@@ -12,5 +12,5 @@ The suggestion that this could be used for
 [[todo/option_to_add_user-specified_string_to_key]] raises its own security
 concerns. (Although git's sha1 collision hardening probably will survive
 until git sha256, so git-annex's attempts to prevent sha1 collisions via
-user-supplied data in the content of keys are probably unncessary.)
+user-supplied data in the content of keys are probably unnecessary.)
 """]]

doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn

@@ -35,5 +35,5 @@ commit -a`). Afterwards, `git status` then smudged it again, unsure why!
 > because restagePointerFile uses the git queue, and unlock 
 > also queues a git add or something, so the queue isn't able to built
 > up because two dissimilar things are being queued. This seems an
-> unncessary behavior; it could queue up all the git adds and then
+> unnecessary behavior; it could queue up all the git adds and then
 > run restagePointerFile after them all. Implemented that, and [[done]]! --[[Joey]]

doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch.mdwn

@@ -30,5 +30,5 @@ Actually -- it made me think: is that `scanning` branch specific? then what woul
 [[!meta author=yoh]]
 [[!tag projects/datalad]]
 
-> I feel this is unncessary complexity and I've optimised the scans quite a
+> I feel this is unnecessary complexity and I've optimised the scans quite a
 > lot in the meantime, so [[wontfix|done]] --[[Joey]]

doc/todo/key_checksum_from_chunk_checksums/comment_3_352bc3eb419184a4ec70ddaffd78968e._comment

@@ -3,7 +3,7 @@
  subject="""comment 3"""
  date="2019-06-26T14:51:32Z"
  content="""
-That seems like an unusual use case that would be unncessary complication
+That seems like an unusual use case that would be unnecessary complication
 to add to git-annex, but that [[external_backends]] could be used to
 implenent as needed.
 """]]

doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_8_b45863d81e3790ea44714a18c1721abd._comment

@@ -7,7 +7,7 @@ For details of the older todo, including some timings with and without
 prelinking, see [[!commit c4229be9a7a2318ef71b9ae433bc14bf604c9caf]].
 
 A ghc bug, since fixed, was causing it to look in IIRC, thousands of
-unncessary directories per library. This todo, by contrast, complains about
+unnecessary directories per library. This todo, by contrast, complains about
 less than 100 extra lookups total.
 
 The way you run the shim does not put the bundled git in PATH. That kind of

doc/todo/more_efficient_resolution_of_trivial_export_conflicts.mdwn

@@ -1,7 +1,7 @@
 Export conflicts happen whenever two repos export different trees 
 to the same special remote.
 
-Some conflicts that seem trivial currently involve unncessary unexporting
+Some conflicts that seem trivial currently involve unnecessary unexporting
 and re-uploading in their resolution.
 
 For example, if A exports a tree containing `[foo]`, and B exports a tree