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

4
doc/design/adjusted_branches.mdwn
View file

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

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

2
doc/design/iabackup.mdwn
View file

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