minor typo fixes throughout
problematic flexibility
This commit is contained in:
parent
4fd28807c1
commit
64e844e1fe
19 changed files with 22 additions and 22 deletions
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue