diff options
| -rw-r--r-- | doc/bugs/copy_fast_confusing_with_broken_locationlog.mdwn | 2 | ||||
| -rw-r--r-- | doc/bugs/dropping_files_with_a_URL_backend_fails.mdwn | 2 | ||||
| -rw-r--r-- | doc/bugs/fat_support.mdwn | 2 | ||||
| -rw-r--r-- | doc/bugs/git_annex_initremote_walks_.git-annex.mdwn | 2 | ||||
| -rw-r--r-- | doc/distributed_version_control.mdwn | 2 | ||||
| -rw-r--r-- | doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn | 4 | ||||
| -rw-r--r-- | doc/forum/wishlist:_special_remote_for_sftp_or_rsync.mdwn | 6 | ||||
| -rw-r--r-- | doc/forum/wishlist:_support_for_more_ssh_urls_.mdwn | 6 | ||||
| -rw-r--r-- | doc/future_proofing.mdwn | 2 | ||||
| -rw-r--r-- | doc/meta.mdwn | 2 | ||||
| -rw-r--r-- | doc/special_remotes/S3.mdwn | 4 | ||||
| -rw-r--r-- | doc/upgrades/SHA_size.mdwn | 2 | ||||
| -rw-r--r-- | doc/walkthrough/unused_data.mdwn | 2 |
13 files changed, 16 insertions, 22 deletions
diff --git a/doc/bugs/copy_fast_confusing_with_broken_locationlog.mdwn b/doc/bugs/copy_fast_confusing_with_broken_locationlog.mdwn index 47fc77fa4..69fbc816f 100644 --- a/doc/bugs/copy_fast_confusing_with_broken_locationlog.mdwn +++ b/doc/bugs/copy_fast_confusing_with_broken_locationlog.mdwn @@ -1,4 +1,4 @@ -Conversation moved from [[walkthrough/recover_data_from_lost+found]] +Conversation moved from [[tips/recover_data_from_lost+found]] to a proper bug. --[[Joey]] (Unfortunatly that scrambled the comment creation times and thus order.) diff --git a/doc/bugs/dropping_files_with_a_URL_backend_fails.mdwn b/doc/bugs/dropping_files_with_a_URL_backend_fails.mdwn index e88bf07f4..c6ef13f84 100644 --- a/doc/bugs/dropping_files_with_a_URL_backend_fails.mdwn +++ b/doc/bugs/dropping_files_with_a_URL_backend_fails.mdwn @@ -1,4 +1,4 @@ -I was trying out the example with the walkthrough [[walkthrough/using_the_URL_backend]]. I tried dropping files that I had after doing an "git annex get ." which have the URL backend associated with the files it fails with +I was trying out the example with the walkthrough using_the_URL_backend. I tried dropping files that I had after doing an "git annex get ." which have the URL backend associated with the files it fails with <pre> diff --git a/doc/bugs/fat_support.mdwn b/doc/bugs/fat_support.mdwn index 60633c29b..70ee3b369 100644 --- a/doc/bugs/fat_support.mdwn +++ b/doc/bugs/fat_support.mdwn @@ -8,8 +8,6 @@ be VFAT formatted: - Use of ":" in filenames of object files, also not supported. Could easily be fixed by reorganizing the object directory. -[[!tag wishlist]] - [[Done]]; in annex.version 2 repos, colons are entirely avoided in filenames. So a bare git clone can be put on VFAT, and git-annex used to move stuff --to and --from it, for sneakernet. diff --git a/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn b/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn index 2457057c8..acd369bde 100644 --- a/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn +++ b/doc/bugs/git_annex_initremote_walks_.git-annex.mdwn @@ -1,4 +1,4 @@ -a [[!taglink minor]] <!-- (a suggestion for introducing severity tags on bugs, +a <!-- (a suggestion for introducing severity tags on bugs, feel free to discard) --> issue: `git annex initremote` (in particular, adding a key as described in [[encryption]] -- `git annex initremote my_remote encryption=my_key`) seems to iterate over the `.git-annex/???/???/*.log` files diff --git a/doc/distributed_version_control.mdwn b/doc/distributed_version_control.mdwn index 738b5adc2..e7c858c69 100644 --- a/doc/distributed_version_control.mdwn +++ b/doc/distributed_version_control.mdwn @@ -14,7 +14,7 @@ repositories what file contents they have available. -- -The [[tutorial]] walks you through creating a distributed set of git-annex +The [[walkthrough]] shows how to create a distributed set of git-annex repositories with no central repository. Prefer a central repository like GitHub? See the diff --git a/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn index f5d5a66bf..cc9091ae5 100644 --- a/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn +++ b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn @@ -2,7 +2,9 @@ I'm not sure if this is my stupidity or if it's a bug, but git annex copy --force --to REMOTE . -just zip's through really quickly and doesn't actually force a copy to a remote location. This is just following up on the [[git-annex directory hashing problems on osx]]. I want to just do a force copy of all my data to my portable disk to really make sure that the data is really there. I would similarly would want to make sure I can force a +just zip's through really quickly and doesn't actually force a copy to a +remote location. This is just following up on the +[[bugs/git-annex_directory_hashing_problems_on_osx]]. I want to just do a force copy of all my data to my portable disk to really make sure that the data is really there. I would similarly would want to make sure I can force a git annex copy --force --from REMOTE . diff --git a/doc/forum/wishlist:_special_remote_for_sftp_or_rsync.mdwn b/doc/forum/wishlist:_special_remote_for_sftp_or_rsync.mdwn index 47e8b8562..7fd31efbc 100644 --- a/doc/forum/wishlist:_special_remote_for_sftp_or_rsync.mdwn +++ b/doc/forum/wishlist:_special_remote_for_sftp_or_rsync.mdwn @@ -1,11 +1,11 @@ -i think it would be useful to have a fourth kind of [[special remote]]s +i think it would be useful to have a fourth kind of [[special_remotes]] that connects to a dumb storage using sftp or rsync. this can be emulated by using sshfs, but that means lots of round-trips through the system and is limited to platforms where sshfs is available. typical use cases are backups to storate shared between a group of people -where each user only has limited access (sftp or rsync), when using [[bup]] -is not an option. +where each user only has limited access (sftp or rsync), when using +[[special_remotes/bup]] is not an option. an alternative to implementing yet another special remote would be to have some kind of plugin system by which external programs can provide an diff --git a/doc/forum/wishlist:_support_for_more_ssh_urls_.mdwn b/doc/forum/wishlist:_support_for_more_ssh_urls_.mdwn deleted file mode 100644 index 661675873..000000000 --- a/doc/forum/wishlist:_support_for_more_ssh_urls_.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -git-annex does not seem to support all kinds of urls that git does. - -> Please use [[bugs]] for bug reports. Moved [[there|bugs/wishlist:_support_for_more_ssh_urls_]]. -> --[[Joey]] - ->> And now all fixed! --[[Joey]] diff --git a/doc/future_proofing.mdwn b/doc/future_proofing.mdwn index 3937e9265..a7bcce37c 100644 --- a/doc/future_proofing.mdwn +++ b/doc/future_proofing.mdwn @@ -34,4 +34,4 @@ problem: metadata. So if a filesystem is badly corrupted and all your annexed files end up in `lost+found`, they can easily be lifted back out into another clone of the repository. Even if the filenames are lost, - it's possible to [[walkthrough/recover_data_from_lost+found]]. + it's possible to [[tips/recover_data_from_lost+found]]. diff --git a/doc/meta.mdwn b/doc/meta.mdwn index f78eaf981..30de003d2 100644 --- a/doc/meta.mdwn +++ b/doc/meta.mdwn @@ -1,4 +1,4 @@ -This wiki contains [[!pagecount pages="pages(*)"]] +This wiki contains [[!pagecount pages="*"]] Broken links: diff --git a/doc/special_remotes/S3.mdwn b/doc/special_remotes/S3.mdwn index 047798e23..d4d3d0238 100644 --- a/doc/special_remotes/S3.mdwn +++ b/doc/special_remotes/S3.mdwn @@ -1,8 +1,8 @@ This special remote type stores file contents in a bucket in Amazon S3 or a similar service. -See [[walkthrough/using_Amazon_S3]] and -[[walkthrough/Internet_Archive_via_S3]] for usage examples. +See [[tips/using_Amazon_S3]] and +[[tips/Internet_Archive_via_S3]] for usage examples. ## configuration diff --git a/doc/upgrades/SHA_size.mdwn b/doc/upgrades/SHA_size.mdwn index 319b91108..97603ba91 100644 --- a/doc/upgrades/SHA_size.mdwn +++ b/doc/upgrades/SHA_size.mdwn @@ -15,6 +15,6 @@ to repository version 2, in each repository run: git annex migrate git commit -m 'migrated keys for v2' -The usual caveats about [[walkthrough/migrating_data_to_a_new_backend]] +The usual caveats about [[tips/migrating_data_to_a_new_backend]] apply; you will end up with unused keys that you can later clean up with `git annex unused`. diff --git a/doc/walkthrough/unused_data.mdwn b/doc/walkthrough/unused_data.mdwn index bd6c39871..518550ac0 100644 --- a/doc/walkthrough/unused_data.mdwn +++ b/doc/walkthrough/unused_data.mdwn @@ -2,7 +2,7 @@ It's possible for data to accumulate in the annex that no files in any branch point to anymore. One way it can happen is if you `git rm` a file without first calling `git annex drop`. And, when you modify an annexed file, the old content of the file remains in the annex. Another way is when -migrating between key-value [[backends|backend]]. +migrating between key-value [[backends]]. This might be historical data you want to preserve, so git-annex defaults to preserving it. So from time to time, you may want to check for such data and |