diff --git a/Annex/AdjustedBranch/Merge.hs b/Annex/AdjustedBranch/Merge.hs index d3031cd478..ee55cf8460 100644 --- a/Annex/AdjustedBranch/Merge.hs +++ b/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. diff --git a/Annex/Content/PointerFile.hs b/Annex/Content/PointerFile.hs index 8d3edf6bd0..6c1ab8fd3b 100644 --- a/Annex/Content/PointerFile.hs +++ b/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) diff --git a/CHANGELOG b/CHANGELOG index 0c600efc39..c1b46c8f53 100644 --- a/CHANGELOG +++ b/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..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 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 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 diff --git a/Database/Keys.hs b/Database/Keys.hs index 218d2f39b9..f376355f23 100644 --- a/Database/Keys.hs +++ b/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 diff --git a/Database/Keys/SQL.hs b/Database/Keys/SQL.hs index 80f9fb60e8..cab4c58759 100644 --- a/Database/Keys/SQL.hs +++ b/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 diff --git a/Remote/Borg.hs b/Remote/Borg.hs index 7c31038661..bbfe166478 100644 --- a/Remote/Borg.hs +++ b/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 diff --git a/Remote/GCrypt.hs b/Remote/GCrypt.hs index f758932bdc..e6d301167a 100644 --- a/Remote/GCrypt.hs +++ b/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 () diff --git a/Remote/Helper/ExportImport.hs b/Remote/Helper/ExportImport.hs index f781275b88..267c6d7ff6 100644 --- a/Remote/Helper/ExportImport.hs +++ b/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. diff --git a/Types/Key.hs b/Types/Key.hs index 014883808a..2717239820 100644 --- a/Types/Key.hs +++ b/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 diff --git a/doc/bugs/Directory_remotes_with_same_mount_point/comment_4_5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment b/doc/bugs/Directory_remotes_with_same_mount_point/comment_4_5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment index 144a178728..ebfd97e4bd 100644 --- a/doc/bugs/Directory_remotes_with_same_mount_point/comment_4_5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment +++ b/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. """]] diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_16_586e591a1e3cc53fd0108da91492c5c2._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_16_586e591a1e3cc53fd0108da91492c5c2._comment index 3d15799ed7..c3f3afa06e 100644 --- a/doc/bugs/Git_repos_corrupt_themselves/comment_16_586e591a1e3cc53fd0108da91492c5c2._comment +++ b/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. """]] diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_18_238bbbcabd626c33acc14f930a7d536c._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_18_238bbbcabd626c33acc14f930a7d536c._comment index 4081cb9fc1..a2ffd63a87 100644 --- a/doc/bugs/Git_repos_corrupt_themselves/comment_18_238bbbcabd626c33acc14f930a7d536c._comment +++ b/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 diff --git a/doc/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_6_3947b44c88820da49d8a2d1afd3595ff._comment b/doc/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_6_3947b44c88820da49d8a2d1afd3595ff._comment index 7753eab2b2..8f4802eaa6 100644 --- a/doc/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_6_3947b44c88820da49d8a2d1afd3595ff._comment +++ b/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. """]] diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment index eaf370fd6e..1cb822e8e7 100644 --- a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment +++ b/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 diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_3_a9b3e07f180ab97f5025d7ce9ca58c05._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_3_a9b3e07f180ab97f5025d7ce9ca58c05._comment index 2bb507eabb..6abc3c9381 100644 --- a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_3_a9b3e07f180ab97f5025d7ce9ca58c05._comment +++ b/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. """]] diff --git a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment index 598da959de..788fd2f2f1 100644 --- a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment +++ b/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 diff --git a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment index bf0b919197..cf6b6f8895 100644 --- a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment +++ b/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. diff --git a/doc/bugs/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn b/doc/bugs/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn index 5f8a21da9c..f5dabbf854 100644 --- a/doc/bugs/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn +++ b/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]] diff --git a/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 b/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 index 851c37da81..d476681451 100644 --- a/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 +++ b/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). """]] diff --git a/doc/bugs/git_keeps_refreshing_index/comment_3_919fb06b3fc7fe9b54797a805873e3c8._comment b/doc/bugs/git_keeps_refreshing_index/comment_3_919fb06b3fc7fe9b54797a805873e3c8._comment index 176c89c133..9ef2fd1544 100644 --- a/doc/bugs/git_keeps_refreshing_index/comment_3_919fb06b3fc7fe9b54797a805873e3c8._comment +++ b/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. """]] diff --git a/doc/bugs/git_keeps_refreshing_index/comment_4_b73f9c5603bc69867e1619d871a8abb7._comment b/doc/bugs/git_keeps_refreshing_index/comment_4_b73f9c5603bc69867e1619d871a8abb7._comment index 104e325c3c..7104488322 100644 --- a/doc/bugs/git_keeps_refreshing_index/comment_4_b73f9c5603bc69867e1619d871a8abb7._comment +++ b/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. """]] diff --git a/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn b/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn index 0489fe40d8..d8d5f49cc7 100644 --- a/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn +++ b/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. diff --git a/doc/design/assistant/syncing/efficiency.mdwn b/doc/design/assistant/syncing/efficiency.mdwn index 09bcc11b69..18f0ca5012 100644 --- a/doc/design/assistant/syncing/efficiency.mdwn +++ b/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 diff --git a/doc/devblog/day_378__finishing_adjusted_branches_merge.mdwn b/doc/devblog/day_378__finishing_adjusted_branches_merge.mdwn index aa0cd1f8d8..2b952f1615 100644 --- a/doc/devblog/day_378__finishing_adjusted_branches_merge.mdwn +++ b/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 diff --git a/doc/devblog/day_483__faster_start_with_removable_drives.mdwn b/doc/devblog/day_483__faster_start_with_removable_drives.mdwn index dfbba15eff..38016e9b74 100644 --- a/doc/devblog/day_483__faster_start_with_removable_drives.mdwn +++ b/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 diff --git a/doc/devblog/day_487__git-annex-shell_p2pstdio.mdwn b/doc/devblog/day_487__git-annex-shell_p2pstdio.mdwn index 2475df87e5..1301d6123e 100644 --- a/doc/devblog/day_487__git-annex-shell_p2pstdio.mdwn +++ b/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. diff --git a/doc/devblog/day_570__brrr.mdwn b/doc/devblog/day_570__brrr.mdwn index 2fa21132ac..451012e3aa 100644 --- a/doc/devblog/day_570__brrr.mdwn +++ b/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 diff --git a/doc/forum/Different_preferred_content_for_subdirs/comment_1_5c1e1e6375360cc9416821085b5a68a8._comment b/doc/forum/Different_preferred_content_for_subdirs/comment_1_5c1e1e6375360cc9416821085b5a68a8._comment index 27c17c4857..8f79912303 100644 --- a/doc/forum/Different_preferred_content_for_subdirs/comment_1_5c1e1e6375360cc9416821085b5a68a8._comment +++ b/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]]. """]] diff --git a/doc/git-annex-adjust.mdwn b/doc/git-annex-adjust.mdwn index 42ec030a20..746e287069 100644 --- a/doc/git-annex-adjust.mdwn +++ b/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`. diff --git a/doc/git-annex-benchmark.mdwn b/doc/git-annex-benchmark.mdwn index 73bb01eb82..3e729c00ea 100644 --- a/doc/git-annex-benchmark.mdwn +++ b/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 diff --git a/doc/git-annex-filter-process.mdwn b/doc/git-annex-filter-process.mdwn index 5ceb66b968..9056e37e88 100644 --- a/doc/git-annex-filter-process.mdwn +++ b/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. diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn index 66968cce11..ac9af004f5 100644 --- a/doc/git-annex.mdwn +++ b/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..annex-trustlevel` diff --git a/doc/special_remotes/gcrypt.mdwn b/doc/special_remotes/gcrypt.mdwn index 94ba546b6c..db9543ed6e 100644 --- a/doc/special_remotes/gcrypt.mdwn +++ b/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.`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. diff --git a/doc/special_remotes/git-lfs.mdwn b/doc/special_remotes/git-lfs.mdwn index 5d3778d0b8..3a6d851de1 100644 --- a/doc/special_remotes/git-lfs.mdwn +++ b/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.`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. diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_13_440624874dd3697dd538655765f2b6a2._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_13_440624874dd3697dd538655765f2b6a2._comment index 9c0208fcd1..e37504992c 100644 --- a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_13_440624874dd3697dd538655765f2b6a2._comment +++ b/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 diff --git a/doc/todo/ditch_yesod.mdwn b/doc/todo/ditch_yesod.mdwn index 0c85ab77d2..d8ef722ae5 100644 --- a/doc/todo/ditch_yesod.mdwn +++ b/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** diff --git a/doc/todo/dynamic_stall_detection.mdwn b/doc/todo/dynamic_stall_detection.mdwn index e91fb9212d..a7db6ae90f 100644 --- a/doc/todo/dynamic_stall_detection.mdwn +++ b/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. diff --git a/doc/todo/external_backends/comment_8_e3c66820da36fe255d07059226690ca4._comment b/doc/todo/external_backends/comment_8_e3c66820da36fe255d07059226690ca4._comment index 16b63c9f14..4738b20fa4 100644 --- a/doc/todo/external_backends/comment_8_e3c66820da36fe255d07059226690ca4._comment +++ b/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.) """]] diff --git a/doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn b/doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn index 1be1517068..2cd819e742 100644 --- a/doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn +++ b/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]] diff --git a/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch.mdwn b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch.mdwn index f9aac29eb5..7fa159769b 100644 --- a/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch.mdwn +++ b/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]] diff --git a/doc/todo/key_checksum_from_chunk_checksums/comment_3_352bc3eb419184a4ec70ddaffd78968e._comment b/doc/todo/key_checksum_from_chunk_checksums/comment_3_352bc3eb419184a4ec70ddaffd78968e._comment index 53209da86b..fc9baaea47 100644 --- a/doc/todo/key_checksum_from_chunk_checksums/comment_3_352bc3eb419184a4ec70ddaffd78968e._comment +++ b/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. """]] diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_8_b45863d81e3790ea44714a18c1721abd._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_8_b45863d81e3790ea44714a18c1721abd._comment index 9a5bc024df..013d634029 100644 --- a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_8_b45863d81e3790ea44714a18c1721abd._comment +++ b/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 diff --git a/doc/todo/more_efficient_resolution_of_trivial_export_conflicts.mdwn b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts.mdwn index a7230bc593..5a6fe0d1e0 100644 --- a/doc/todo/more_efficient_resolution_of_trivial_export_conflicts.mdwn +++ b/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