Replace master with main

5 files changed, 12 insertions, 12 deletions

diff --git a/samples/Directory.Build.props b/samples/Directory.Build.props
index 7a4a6c49..8b38f0a8 100644
--- a/samples/Directory.Build.props
+++ b/samples/Directory.Build.props
@@ -2,7 +2,7 @@
  <!--
     This file is intended as a best practice for using sourcelink.
     https://github.com/dotnet/sourcelink
-    
+
     At Microsoft, we have three build types:
 
     Official build:
@@ -14,11 +14,11 @@
     - ContinuousIntegrationBuild property is set to true
     - Embeds PDBs to make it easier to debug crash dumps captured on the CI machine.
     Developer build:
-    - Embeds PDBs to be consistent with PR validation build.   
-    
-    Context: 
-    * https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/ProjectDefaults.props
-    * https://github.com/dotnet/sourcelink/tree/master/docs#continuousintegrationbuild
+    - Embeds PDBs to be consistent with PR validation build.
+
+    Context:
+    * https://github.com/dotnet/arcade/blob/main/src/Microsoft.DotNet.Arcade.Sdk/tools/ProjectDefaults.props
+    * https://github.com/dotnet/sourcelink/tree/main/docs#continuousintegrationbuild
  -->
 
     <PropertyGroup>
diff --git a/samples/RaspberryPiInstructions.md b/samples/RaspberryPiInstructions.md
index d40cfce5..32e604fd 100644
--- a/samples/RaspberryPiInstructions.md
+++ b/samples/RaspberryPiInstructions.md
@@ -74,6 +74,6 @@ It is possible to setup VS Code for remote debugging. Please refer to [Scott Han
 
 ## GPIO access / communicating with hardware
 
-GPIO access as well as I2C, SPI, PWM and many more can be achieved with [.NET IoT](https://github.com/dotnet/iot). For list of available devices please refer to [device listing](https://github.com/dotnet/iot/blob/master/src/devices/README.md).
+GPIO access as well as I2C, SPI, PWM and many more can be achieved with [.NET IoT](https://github.com/dotnet/iot). For list of available devices please refer to [device listing](https://github.com/dotnet/iot/blob/main/src/devices/README.md).
 
 Please consider contributing to the repository or filing an issue if you cannot find the device you're looking for!
diff --git a/samples/dependadotnet/README.md b/samples/dependadotnet/README.md
index 0dc642e9..1265664e 100644
--- a/samples/dependadotnet/README.md
+++ b/samples/dependadotnet/README.md
@@ -4,7 +4,7 @@ Dependadotnet generates [Dependabot](https://docs.github.com/en/free-pro-team@la
 
 Dependabot works out of the box if you have a solution (`.sln`) or project file (like `.csproj`) at the root of the repo. It also supports `packages.config`.
 
-This tool is for repos that contain projects that are [not discoverable from any one location](https://github.com/dependabot/feedback/issues/632). [dotnet/samples](https://github.com/dotnet/samples) is a good example of this case, and has a [dependabot.yml](https://github.com/dotnet/samples/blob/master/.github/dependabot.yml) (generated by this tool) that describes all projects within the repo.
+This tool is for repos that contain projects that are [not discoverable from any one location](https://github.com/dependabot/feedback/issues/632). [dotnet/samples](https://github.com/dotnet/samples) is a good example of this case, and has a [dependabot.yml](https://github.com/dotnet/samples/blob/main/.github/dependabot.yml) (generated by this tool) that describes all projects within the repo.
 
 Dependabot also supports specifying ranges of package versions that should be ignored as candidates for updates. The dependadotnet tool uses a [database](package-ignore.json) ([source](https://github.com/richlander/dependabot-data-processing)) that maps target frameworks to incompatible package versions, and generates dependabot manifests to match ([example](https://github.com/richlander/dependabot-dotnet-test-projects/blob/main/.github/dependabot.yml)).
 
diff --git a/samples/dotnetsay/README.md b/samples/dotnetsay/README.md
index 115e32d2..6ccc00dc 100644
--- a/samples/dotnetsay/README.md
+++ b/samples/dotnetsay/README.md
@@ -75,7 +75,7 @@ You can make tools and libraries debuggable with [Source Link](https://github.co
 
 When you or your users debug your binaries with Source Link, the debugger will attempt to retrieve content (like `.cs` files) from the recorded git commit in your binaries. The given commit needs to be published to a public or accessible private repo in order for that to work. This means that you should build from a branch whose commits are stable and already published. You can build from a PR branch, but the commits may not remain stable for long, as the PRs may be [squashed on merge](https://help.github.com/articles/about-pull-request-merges/).
 
-For official builds, we recommend that you enable [`ContinuousIntegrationBuild`](https://github.com/dotnet/sourcelink/blob/master/docs/README.md#continuousintegrationbuild), so that the built artifacts are [reproducible and deterministic](https://reproducible-builds.org/) (same outcome independent of build machine or time).
+For official builds, we recommend that you enable [`ContinuousIntegrationBuild`](https://github.com/dotnet/sourcelink/blob/main/docs/README.md#continuousintegrationbuild), so that the built artifacts are [reproducible and deterministic](https://reproducible-builds.org/) (same outcome independent of build machine or time).
 
 The [dotnetsay project](dotnetsay.csproj) doesn't add these properties or the `PackageReference` but relies on the same information in the [Directory.Build.props](../Directory.Build.props) in the parent directory. The use of a Directory.Build.props is recommended for Source Link, to avoid maintaining these settings in multiple project files.
 
@@ -93,6 +93,6 @@ Set `Debugger Type` to `Managed (CoreCLR)` in `Properties`. Then `Step Into new
 
 ![debugging-dotnetsay-configure](https://user-images.githubusercontent.com/2608468/40098555-db8cd828-5890-11e8-9549-b3bb1746c187.png)
 
-You will be asked if you want to download source from GitHub. After that, you will then be able to step through the execution of the tool. 
+You will be asked if you want to download source from GitHub. After that, you will then be able to step through the execution of the tool.
 
 ![debugging-dotnetsay](https://user-images.githubusercontent.com/2608468/40098638-5a2be8b8-5891-11e8-83e7-905aa445c2fe.png)
diff --git a/samples/linker-instructions-advanced.md b/samples/linker-instructions-advanced.md
index f13b6eb9..37c1bb4f 100644
--- a/samples/linker-instructions-advanced.md
+++ b/samples/linker-instructions-advanced.md
@@ -34,7 +34,7 @@ Root assemblies can be specified with the `LinkerRootAssemblies` ItemGroup:
 
 This ItemGroup should contain the logical names of assemblies, not the filenames (so the assembly names should not have extensions).
 
-The linker roots can also be specified at a more granular level using XML root descriptor files, whose format is [documented](https://github.com/mono/linker/tree/master/src/linker#syntax-of-xml-descriptor) in the mono/linker repo. These files should be specified in the LinkerRootDescriptors ItemGroup:
+The linker roots can also be specified at a more granular level using XML root descriptor files, whose format is [documented](https://github.com/mono/linker/blob/main/docs/data-formats.md#descriptor-format) in the mono/linker repo. These files should be specified in the LinkerRootDescriptors ItemGroup:
 
 ```xml
 <ItemGroup>
@@ -82,4 +82,4 @@ The ILLink task can be invoked just like any other msbuild task. For example, it
 </Target>
 ```
 
-Here, the ItemGroups `AssemblyFilesToLink`, `LinkerRootAssemblies`, and `LinkerRootDescriptors` would be defined elsewhere in the project, and the `ExtraArgs` input consists of flags described in the [mono/linker documentation](https://github.com/mono/linker/blob/master/README.md). By default, the `RootAssemblyNames` are rooted as if illink had been called with `-a RootAssemblyName1 -a RootAssemblyName2` ... as arguments, but this behavior is subject to change and should not be relied upon.
+Here, the ItemGroups `AssemblyFilesToLink`, `LinkerRootAssemblies`, and `LinkerRootDescriptors` would be defined elsewhere in the project, and the `ExtraArgs` input consists of flags described in the [mono/linker documentation](https://github.com/mono/linker/blob/main/docs/illink-tasks.md#extraargs). By default, the `RootAssemblyNames` are rooted as if illink had been called with `-a RootAssemblyName1 -a RootAssemblyName2` ... as arguments, but this behavior is subject to change and should not be relied upon.