Typo fix unncessary -> unnecessary.

Detected while reading recent CHANGELOG entry but then decided to apply
to entire codebase and docs since why not?
This commit is contained in:
Yaroslav Halchenko 2022-08-19 17:45:04 -04:00 committed by Joey Hess
parent f091eff476
commit 0151976676
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
43 changed files with 60 additions and 60 deletions

View file

@ -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.
"""]]

View file

@ -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.
"""]]

View file

@ -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

View file

@ -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.
"""]]

View file

@ -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

View file

@ -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.
"""]]

View file

@ -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

View file

@ -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.

View file

@ -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]]

View file

@ -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).
"""]]

View file

@ -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.
"""]]

View file

@ -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.
"""]]

View file

@ -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.