diff --git a/Annex/Locations.hs b/Annex/Locations.hs index 0d71ef92e7..9b38566025 100644 --- a/Annex/Locations.hs +++ b/Annex/Locations.hs @@ -411,7 +411,7 @@ gitAnnexAssistantDefaultDir = "annex" - - This is used when a new Key is initially being generated, eg by getKey. - Unlike keyFile and fileKey, it does not need to be a reversable - - escaping. Also, it's ok to change this to add more problimatic + - escaping. Also, it's ok to change this to add more problematic - characters later. Unlike changing keyFile, which could result in the - filenames used for existing keys changing and contents getting lost. - diff --git a/Assistant/Restart.hs b/Assistant/Restart.hs index 70b236fae9..e9d152ab7f 100644 --- a/Assistant/Restart.hs +++ b/Assistant/Restart.hs @@ -91,7 +91,7 @@ newAssistantUrl repo = do {- Checks if the assistant is listening on an url. - - - Always checks http, because https with self-signed cert is problimatic. + - Always checks http, because https with self-signed cert is problematic. - warp-tls listens to http, in order to show an error page, so this works. -} assistantListening :: URLString -> IO Bool diff --git a/Build/BundledPrograms.hs b/Build/BundledPrograms.hs index 4e6d2081e1..69d72b4610 100644 --- a/Build/BundledPrograms.hs +++ b/Build/BundledPrograms.hs @@ -70,7 +70,7 @@ preferredBundledPrograms = catMaybes , Just "sh" #endif #ifndef darwin_HOST_OS - -- wget on OSX has been problimatic, looking for certs in the wrong + -- wget on OSX has been problematic, looking for certs in the wrong -- places. Don't ship it, use curl or the OSX's own wget if it has -- one. , ifset SysConfig.wget "wget" diff --git a/Build/EvilSplicer.hs b/Build/EvilSplicer.hs index cfdcc3a6f5..e685b1e443 100644 --- a/Build/EvilSplicer.hs +++ b/Build/EvilSplicer.hs @@ -620,7 +620,7 @@ mangleCode = flip_colon void $ string "= " return $ "= do { " ++ x ++ " <- return $ " -{- Embedded files use unsafe packing, which is problimatic +{- Embedded files use unsafe packing, which is problematic - for several reasons, including that GHC sometimes omits trailing - newlines in the file content, which leads to the wrong byte - count. Also, GHC sometimes outputs unicode characters, which diff --git a/CHANGELOG b/CHANGELOG index 897204f9d4..06c9974dfb 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -3534,7 +3534,7 @@ git-annex (3.20120430) unstable; urgency=low (Requested by the Internet Archive) * uninit: Clear annex.uuid from .git/config. Closes: #670639 * Added shared cipher mode to encryptable special remotes. This option - avoids gpg key distribution, at the expense of flexability, and with + avoids gpg key distribution, at the expense of flexibility, and with the requirement that all clones of the git repository be equally trusted. -- Joey Hess Mon, 30 Apr 2012 13:16:10 -0400 diff --git a/Git/Queue.hs b/Git/Queue.hs index 086b5a56fd..0b0025b0a7 100644 --- a/Git/Queue.hs +++ b/Git/Queue.hs @@ -163,7 +163,7 @@ runAction repo action@(CommandAction {}) = do hPutStr h $ intercalate "\0" $ toCommand $ getFiles action hClose h #else - -- Using xargs on Windows is problimatic, so just run the command + -- Using xargs on Windows is problematic, so just run the command -- once per file (not as efficient.) if null (getFiles action) then void $ boolSystemEnv "git" gitparams (gitEnv repo) diff --git a/Types/MetaData.hs b/Types/MetaData.hs index 198fe5d7d5..449548d53e 100644 --- a/Types/MetaData.hs +++ b/Types/MetaData.hs @@ -95,7 +95,7 @@ instance MetaSerializable MetaField where serialize (MetaField f) = CI.original f deserialize = Just . mkMetaFieldUnchecked -{- Base64 problimatic values. -} +{- Base64 problematic values. -} instance MetaSerializable MetaValue where serialize (MetaValue isset v) = serialize isset ++ diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment index 89af53b419..558a1ce23a 100644 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment +++ b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment @@ -21,5 +21,5 @@ The MSDN article has one very interesting bit: (It seems that, when using that prefix, `/` is not converted to `\` .. I think git-annex is quite good about getting the slashes the right way round these days.) -So it might be possible for git-annex to use that prefix and avoid this issue entirely. Haskell's FilePath library does understand that prefix (treats it as part of the drive). Since git-annex always uses the path to the top of the Repo when constructing the problimatic FilePaths, I might be able to just change the Repo constructor to add that prefix, and everything follow from that. I tried doing that, unfortunately this makes *git* fail, with \"fatal: relative path syntax cannot be used outside working tree\" when operating on such a repo. Cause git doesn't understand that prefix. +So it might be possible for git-annex to use that prefix and avoid this issue entirely. Haskell's FilePath library does understand that prefix (treats it as part of the drive). Since git-annex always uses the path to the top of the Repo when constructing the problematic FilePaths, I might be able to just change the Repo constructor to add that prefix, and everything follow from that. I tried doing that, unfortunately this makes *git* fail, with \"fatal: relative path syntax cannot be used outside working tree\" when operating on such a repo. Cause git doesn't understand that prefix. """]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment index e0f73a82f6..4d2916712e 100644 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment +++ b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment @@ -34,11 +34,11 @@ The only option on the git-annex side would be to add an option to totally disable use of locks, which would make it rather unsafe to use. Or to use only dotlocks (file existence level locks). -Dotlocks are problimatic. Some of the uses git-annex makes of locking, +Dotlocks are problematic. Some of the uses git-annex makes of locking, like using both shared and exclusive locks on a file to let multiple concurrent readers, would be very hard to emulate with dotlocks. Also, dotlocks go stale when processes die, and git-annex uses lots of different -locks in different places, which would be problimatic to clean up in such +locks in different places, which would be problematic to clean up in such a situation. I think that it might make sense, if git-annex has to fall back to dotlocks, diff --git a/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment b/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment index 382f8c835b..a0f452b5dc 100644 --- a/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment +++ b/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment @@ -11,7 +11,7 @@ joeyh so, my thought is that perhaps you had a git-annex process before that was joeyh for example, if you ran it and ctrl-z'd at just the right time, it could be suspended and holding the lock joeyh (or the kernel coud have gotten confused, which given you also had a crash, who knows..) dp sounds logical -joeyh forcing locks is always a problimatic thing +joeyh forcing locks is always a problematic thing joeyh but git-annex could certainly notice if it seems to be stalled and print some useful messages joeyh and maybe have a way to run with locks forced diff --git a/doc/design/adjusted_branches.mdwn b/doc/design/adjusted_branches.mdwn index 79231247c4..7946e6405e 100644 --- a/doc/design/adjusted_branches.mdwn +++ b/doc/design/adjusted_branches.mdwn @@ -229,7 +229,7 @@ better to delete it from the work tree, but keep the branch as-is. Then But, not maintaining an adjusted branch complicates other things. See WORKTREE notes throughout this page. Overall, the WORKTREE approach seems -too problimatic. +too problematic. Ah, but we know that when adjustment #2 is in place, any file that `git annex get` could act on is not in the index. So, it could look at the master branch @@ -242,7 +242,7 @@ index in that case. ## problems -Using `git checkout` when in an adjusted branch is problimatic, because a +Using `git checkout` when in an adjusted branch is problematic, because a non-adjusted branch would then be checked out. But, we can just say, if you want to get into an adjusted branch, you have to run git annex adjust Or, could make a post-checkout hook. This is would mostly be confusing when diff --git a/doc/design/assistant/blog/day_110__more_dropping.mdwn b/doc/design/assistant/blog/day_110__more_dropping.mdwn index afa256c776..71fb01ab12 100644 --- a/doc/design/assistant/blog/day_110__more_dropping.mdwn +++ b/doc/design/assistant/blog/day_110__more_dropping.mdwn @@ -11,7 +11,7 @@ if this will slow down git-annex in some use cases; might need to add more higher-level caching. It was a very minimal cache anyway, just of one file. Removed support for "in=" from preferred content expressions. That was -problimatic in two ways. First, it referred to a remote by name, but +problematic in two ways. First, it referred to a remote by name, but preferred content expressions can be evaluated elsewhere, where that remote doesn't exist, or a different remote has the same name. This name lookup code could error out at runtime. Secondly, "in=" seemed pretty useless, and diff --git a/doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment b/doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment index e47b03d48d..09613cc906 100644 --- a/doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment +++ b/doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment @@ -6,5 +6,5 @@ content=""" That's a good question. Unfortunatly they cannot; X and Y need to be stable across repositories, and git remotes can have different names in different repositories. -Even using the description that git-annex stores for each repository for X and Y is problimatic, since that description can change, and so could be different in two repos that are each trying to resolve the same merge conflict. +Even using the description that git-annex stores for each repository for X and Y is problematic, since that description can change, and so could be different in two repos that are each trying to resolve the same merge conflict. """]] diff --git a/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn b/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn index 8107336f03..4d7c9582e1 100644 --- a/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn +++ b/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn @@ -7,7 +7,7 @@ I didn't have to add many stubs today, either. Many of the missing Windows features were only used in code paths that made git-annex faster, but I could fall back to a slower code path on Windows. -The things that are most problimatic so far: +The things that are most problematic so far: * POSIX file locking. This is used in git-annex in several places to make it safe when multiple git-annex processes are running. I put in diff --git a/doc/design/iabackup.mdwn b/doc/design/iabackup.mdwn index da437aa192..8133c2332d 100644 --- a/doc/design/iabackup.mdwn +++ b/doc/design/iabackup.mdwn @@ -92,7 +92,7 @@ decided to remove content. annex.diskreserve) 2. Note that [[numcopies|copies]] and [[preferred_content]] settings can be used to make clients only want to download an file if it's not yet - reached the desired number of copies. Lots of flexability here in + reached the desired number of copies. Lots of flexibility here in git-annex. 3. git-annex will push back to the server an updated git-annex branch, which will record when it has successfully stored an file. diff --git a/doc/devblog/day_232__OSX_Yosemite.mdwn b/doc/devblog/day_232__OSX_Yosemite.mdwn index c8521fbd4e..468d7030ef 100644 --- a/doc/devblog/day_232__OSX_Yosemite.mdwn +++ b/doc/devblog/day_232__OSX_Yosemite.mdwn @@ -3,4 +3,4 @@ The OSX autobuilder has been updated to OSX 10.10 Yosemite. The might also work on 10.9 Mavericks too, and I'd appreciate help testing that. Went ahead and fixed the [[partial commit problem|bugs/modified_permissions_persist_after_unlock__44___commit]] -by making the pre-commit hook detect and block problimatic partial commits. +by making the pre-commit hook detect and block problematic partial commits. diff --git a/doc/devblog/day_248__workload_tuning.mdwn b/doc/devblog/day_248__workload_tuning.mdwn index ba8224ecc6..d1fee2926c 100644 --- a/doc/devblog/day_248__workload_tuning.mdwn +++ b/doc/devblog/day_248__workload_tuning.mdwn @@ -10,7 +10,7 @@ Today I put together a lot of things I've been thinking about: * There are other changes some would like to see (like lower-case object hash directory names) that are certianly not enough to warrant a flag day repo format upgrade. -* It would be nice to let people who want to have some flexability to play +* It would be nice to let people who want to have some flexibility to play around with changes, in their own repos, as long as they don't a) make git-annex a lot more complicated, or b) negatively impact others. (Without having to fork git-annex.) diff --git a/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_2_d04b7adcc17a305fb1d7f1c1a3641be1._comment b/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_2_d04b7adcc17a305fb1d7f1c1a3641be1._comment index a13631845b..9cf4f8c202 100644 --- a/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_2_d04b7adcc17a305fb1d7f1c1a3641be1._comment +++ b/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_2_d04b7adcc17a305fb1d7f1c1a3641be1._comment @@ -18,7 +18,7 @@ If you are using a mixture of filesystems, eg EXT4 and VFAT, this can still result in WORM key names generated on EXT4 being too long to fit on the VFAT filesystem. In this case, I would recommend not using WORM. -Incidentially, that version also made many problimatic characters +Incidentially, that version also made many problematic characters not be included in WORM key names, so they're more portable to eg, FAT filesystems. """]] diff --git a/doc/forum/How_to_revert_metadata_changes/comment_1_de40f1a3f364ca6d2f9bb489f4d64cb3._comment b/doc/forum/How_to_revert_metadata_changes/comment_1_de40f1a3f364ca6d2f9bb489f4d64cb3._comment index 6edf7a161e..da47be164d 100644 --- a/doc/forum/How_to_revert_metadata_changes/comment_1_de40f1a3f364ca6d2f9bb489f4d64cb3._comment +++ b/doc/forum/How_to_revert_metadata_changes/comment_1_de40f1a3f364ca6d2f9bb489f4d64cb3._comment @@ -16,7 +16,7 @@ complications: file. This will cause git-annex to re-generate its index from the new contents of the branch. 2. Resetting the git-annex branch to a previous rev won't "stick" - if the problimatic rev has already been pushed to other repositories. + if the problematic rev has already been pushed to other repositories. git-annex will automatically re-merge the git-annex branches from other repos at some point and get the problem rev back. Instead you'll need to make a commit to the git-annex branch that undoes the changes made by the @@ -24,7 +24,7 @@ complications: 3. The contents of the git-annex branch are merged by essentially taking the union of the local and remote contents. So if some other clone of the repository still has the - problimatic data in its git-annex branch, when git-annex union + problematic data in its git-annex branch, when git-annex union merges that in, the problem data will come back again, even if you've made a local commit that reverts its addition.