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

fix typos.

Browse source
This commit is contained in:
Mesar Hameed 2014-07-19 23:57:04 +01:00
parent 5dac6c3c25
commit 57f735b520
4 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone./comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment
View file

@ -4,7 +4,7 @@
subject="comment 1"
date="2013-09-12T21:29:39Z"
content="""
The git-annex webapp displays a view from \"inside\" one git repsitory at a time. It seems to me that you have two or more local git repositories; one in ~/annex and one on a removable drive. The webapp is coming up viewing from inside your removable drive's repository. You can change the repository that the webapp views by going to the Repository menu in the upper-right corner and selecting Switch repository. The webapp will remember which repository it viewed last, and come back up showing that same repository.
The git-annex webapp displays a view from \"inside\" one git repository at a time. It seems to me that you have two or more local git repositories; one in ~/annex and one on a removable drive. The webapp is coming up viewing from inside your removable drive's repository. You can change the repository that the webapp views by going to the Repository menu in the upper-right corner and selecting Switch repository. The webapp will remember which repository it viewed last, and come back up showing that same repository.
It's BTW an unusual configuration to have the git-annex assistant directly running on a removable drive as you seem to have done. You must have previously went to the Repository menu and selected \"Add another local repository\", and then added the removable drive, and then connected that repository up to your ~/annex repository. Which would explain why the webapp was last showing the repository on the removable drive. The more usual way to add a removable drive is to use the \"Add another repository\" button and select \"Removable drive\".

2
doc/forum/ignore_changes_made_by_a_remote/comment_1_825676069d2e1554499b76fd8c306c30._comment
View file

@ -4,7 +4,7 @@
subject="comment 1"
date="2014-04-02T20:02:19Z"
content="""
I don't see any need to scrap the repository. Since you have an indirect mode repsitory, you can use `git log` in there to find commits you don't like, and run `git revert` to revert them. So if a bad commit comes down from windows, you can just undo it. That's why we use git, yes?
I don't see any need to scrap the repository. Since you have an indirect mode repository, you can use `git log` in there to find commits you don't like, and run `git revert` to revert them. So if a bad commit comes down from windows, you can just undo it. That's why we use git, yes?
I'm much more curious about the circumstances that cause empty files to end up in the direct mode repository.
"""]]

2
doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_10_4440a80d64c60c7312d5c405d54e607a._comment
View file

@ -9,7 +9,7 @@
Sorry, I ment that the file containing the symmetric encryption key should obviously not be used to encrypt itself, it would be stored in the repository \"unencrypted\" (but protected with a passphrase)
> store a non-encrypted gpg key alongside the repsitory encrypted with it, but then you have to rely on a passphrase for all your security.
> store a non-encrypted gpg key alongside the repository encrypted with it, but then you have to rely on a passphrase for all your security.
Exactly. I think such a mode be a great addition. It might not be as secure as encryption based on a private key - depending on the passphrase strength -, but it would certainly be a lot more convenient and portable (and still much more secure than the shared encryption method).
"""]]

2
doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment
View file

@ -8,7 +8,7 @@
Then you would need to decrypt the repository in order get the key you need to decrypt the repository. The impossibility of this design is why I didn't do that!
It would certainly be possible to store a non-encrypted gpg key alongside the repsitory encrypted with it, but then you have to rely on a passphrase for all your security.
It would certainly be possible to store a non-encrypted gpg key alongside the repository encrypted with it, but then you have to rely on a passphrase for all your security.
You should file a bug report for the bug you saw..
"""]]