fix broken links

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

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>

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.

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

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

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 .
 

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]]
+where each user only has limited access (sftp or rsync), when using
-is not an option.
+[[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

doc/forum/wishlist:_support_for_more_ssh_urls_.mdwn

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

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

doc/meta.mdwn

@@ -1,4 +1,4 @@
-This wiki contains [[!pagecount pages="pages(*)"]]
+This wiki contains [[!pagecount pages="*"]]
 
 Broken links:
 

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
+See [[tips/using_Amazon_S3]] and
-[[walkthrough/Internet_Archive_via_S3]] for usage examples.
+[[tips/Internet_Archive_via_S3]] for usage examples.
 
 ## configuration
 

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

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