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
Joey Hess
parent
f091eff476
commit
0151976676
43 changed files with 60 additions and 60 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
30
CHANGELOG
30
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 ()
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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]]
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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]].
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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**
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.)
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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]]
|
||||
|
|
|
|||
|
|
@ -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]]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue