mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

minor typo fixes throughout

Browse source 
problematic
flexibility
This commit is contained in:
Yaroslav Halchenko 2016-06-01 21:46:58 -04:00 • committed by Joey Hess
parent 4fd28807c1
commit 64e844e1fe
Failed to extract signature
19 changed files with 22 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/design/assistant/blog/day_110__more_dropping.mdwn
View file

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

2
doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment
View file

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

2
doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn
View file

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