minor typo fixes throughout

problematic
flexibility

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

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,

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
 </pre>

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

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

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

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

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.

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.

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

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

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.