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

correct spelling mistakes

Browse source
This commit is contained in:
Edward Betts 2017-02-11 09:38:49 +00:00 • committed by Joey Hess
parent 5e6ced7d0f
commit 0750913136
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
52 changed files with 69 additions and 69 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment
View file

@ -6,7 +6,7 @@
content="""
\"Checking out files\" is a message printed by git (not by git-annex) when it is updating the work tree.
It still seems that you have somehow committed large files directly to git. Perhaps you accidentially ran \"git add\" on a large file.
It still seems that you have somehow committed large files directly to git. Perhaps you accidentally ran \"git add\" on a large file.
git annex sync is probably merging this commit from one of your other repositories.
"""]]

2
doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment
View file

@ -9,7 +9,7 @@ A few likely reasons:
* If a 4th client repository had popped up.
* If you have configured a high number of copies, it might only be able to be met by keeping files on the transfer repository.
* Similarly, if a repository that used to have the files has been marked as dead or deleted, more copies might be needed to make up for that.
* For completeness, if the transfer repository accidentially had its type changed to some other kind of repository, like a full backup.
* For completeness, if the transfer repository accidentally had its type changed to some other kind of repository, like a full backup.
You can enable debugging (start with --debug or go into the webapp's preferences) and it might say a little more, but the debugging info is not very good.

2
doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment
View file

@ -16,5 +16,5 @@ too many files to look at.
Another approach is to look at the git log, find the commit that merged
the unwanted changed (and created these variant files), and `git revert` that
merge, and the earlier commit that was made accidentially.
merge, and the earlier commit that was made accidentally.
"""]]

2
doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment
View file

@ -3,7 +3,7 @@
subject="""comment 2"""
date="2015-09-09T18:18:17Z"
content="""
I wish this incompatability didn't exist either, but the transition to use
I wish this incompatibility didn't exist either, but the transition to use
consistently 3 letter hash directories would be too much to ask of all the
users. And there are ways to convert a bare to non-bare that don't have
this problem, like making a clone and using `git annex move --all --from

2
doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment
View file

@ -26,5 +26,5 @@ And here for a binary file stored in git:
If you find the latter in the log, then the author and commit message of the commit adding it would be interesting.
Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentially committed it directly to git.
Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentally committed it directly to git.
"""]]

4
doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment
View file

@ -7,8 +7,8 @@
From the man page:
> Until a repository (**or one of its remotes**) has been initialized
> git-annex will refuse to operate on it, to avoid accidentially
> using it in a repository that was not intended tohave an annex.
> git-annex will refuse to operate on it, to avoid accidentally
> using it in a repository that was not intended to have an annex.
So, yes, it assumes that if a repository has a git-annex branch already, git-annex is being used, and no explicit init is necessary. You can still run `git annex init` after the fact if you like.
"""]]

2
doc/forum/webapp_does_not_start.mdwn
View file

@ -42,7 +42,7 @@ EDIT:
Exception: .t/tmprepo9/.git/annex/journal: getDirectoryContents: permission denied (Access is denied.)
2 out of 83 tests failed
(This could be due to a bug in git-annex, or an incompatability
(This could be due to a bug in git-annex, or an incompatibility
with utilities, such as git, installed on this system.)