Replace outdated snapshot links

I have moved the snapshots from Azure Blobs a long time ago. While there
_is_ a redirect in place, it's better to link to the correct place to
begin with.

Signed-off-by: Johannes Schindelin <[email protected]>

Author: dscho

content/faq.md

@@ -60,7 +60,7 @@ For extracting 7z/zip archives see [page](./zip-archives-extracting-the-released
 
 ## Are there 'Nightly' builds of the latest and greatest
 
-The Git for Windows builds are not quite that frequent, but there are Snapshot builds listed at https://wingit.blob.core.windows.net/files/index.html
+The Git for Windows builds are not quite that frequent, but there are [Snapshot builds](https://gitforwindows.org/git-snapshots/).
 
 These often 'fix' (or attempt fixes) recent issues before a new formal release. Check their commit notes and links to issues to see if your problem is included.
 

content/releasing-git-for-windows.md

@@ -128,11 +128,11 @@ Sadly, things are broken a lot. In those cases, the logs have to be analyzed, an
 
 This step is trivial: `git push origin <branch>:main` where `<branch>` is something like `rebase-to-v2.37.0`.
 
-This will trigger another "Git artifacts" run, which will figure out that there is a GitHub Release for that commit, download those artifacts, then trigger a run of [the `Snapshots` Release Pipeline](https://dev.azure.com/git-for-windows/git/_release?definitionId=2&view=mine&_a=releases), which will then upload [the snapshot](https://wingit.blob.core.windows.net/files/index.html).
+This will trigger another "Git artifacts" run, which will figure out that there is a GitHub Release for that commit, download those artifacts, then trigger a run of [the `Snapshots` Release Pipeline](https://dev.azure.com/git-for-windows/git/_release?definitionId=2&view=mine&_a=releases), which will then upload [the snapshot](https://gitforwindows.org/git-snapshots/).
 
 It is important to wait with pushing to `main` until there is a GitHub Release, otherwise the "Git artifacts" Pipeline would build _another_ set of artifacts and upload those, but we do want to use the same artifacts as were uploaded to GitHub Releases.
 
-Note: The idea is to push to `main` relatively soon after the Release Pipeline finished, to keep the Pacman repository, the [snapshots](https://wingit.blob.core.windows.net/files/index.html) and the `main` branches as aligned as possible.
+Note: The idea is to push to `main` relatively soon after the Release Pipeline finished, to keep the Pacman repository, the [snapshots](https://gitforwindows.org/git-snapshots/) and the `main` branches as aligned as possible.
 
 
 ## How to release a quick-fix release

content/snapshot-builds.md

@@ -7,7 +7,7 @@ Git for Windows' `main` branch is kept in an always-releasable state as much as
 
 For example, in case that a critical bug is discovered that really needs to be fixed within the same day, Git for Windows does not have a maintenance branch (or, "stable" branch). Such a fix would be applied on top of `main` and a new version would be created from that state.
 
-To allow users to help verifying that "always-releasable state", as well as to allow users to verify fixes introduced via PRs, Git for Windows builds "snapshot" releases (published [here](https://wingit.blob.core.windows.net/files/index.html)) whenever the `main` branch advances.
+To allow users to help verifying that "always-releasable state", as well as to allow users to verify fixes introduced via PRs, Git for Windows builds "snapshot" releases (published [here](https://gitforwindows.org/git-snapshots/)) whenever the `main` branch advances.
 
 Those snapshot releases are considered robust. They are built using [the exact same Azure Pipeline](https://dev.azure.com/git-for-windows/git/_build?definitionId=34&_a=summary) that also builds official Git for Windows versions (as well as the `-rc` pre-releases leading up to every major version). Snapshot versions come in the same flavors as full Git for Windows versions: 32-bit and 64-bit, installers, portable Gits, MinGits.