Change the default branch name to default

No matter how well-intentioned the current choice of the default branch
name is, it is undeniable that it is a loaded term, causing all kinds of
totally unwanted emotional harm.

So let's go ahead and start the long process of changing it to a better
name.

Signed-off-by: Don Goodman-Wilson <don@goodman-wilson.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Documentation/Makefile

@@ -49,7 +49,7 @@ endif
 
 MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT))
 MAN_HTML = $(patsubst %.txt,%.html,$(MAN_TXT))
-GIT_MAN_REF = master
+GIT_MAN_REF = default
 
 OBSOLETE_HTML += everyday.html
 OBSOLETE_HTML += git-remote-helpers.html

Documentation/MyFirstContribution.txt

@@ -113,15 +113,15 @@ commands such as `sl`.)
 
 Let's start by making a development branch to work on our changes. Per
 `Documentation/SubmittingPatches`, since a brand new command is a new feature,
-it's fine to base your work on `master`. However, in the future for bugfixes,
+it's fine to base your work on `default`. However, in the future for bugfixes,
 etc., you should check that document and base it on the appropriate branch.
 
-For the purposes of this document, we will base all our work on the `master`
+For the purposes of this document, we will base all our work on the `default`
 branch of the upstream project. Create the `psuh` branch you will use for
 development like so:
 
 ----
-$ git checkout -b psuh origin/master
+$ git checkout -b psuh origin/default
 ----
 
 We'll make a number of commits here in order to demonstrate how to send a topic
@@ -417,7 +417,7 @@ the declarations and the logic, respectively.
 
 ...
 
-	c = lookup_commit_reference_by_name("origin/master");
+	c = lookup_commit_reference_by_name("origin/default");
 
 	if (c != NULL) {
 		pp_commit_easy(CMIT_FMT_ONELINE, c, &commitline);
@@ -438,12 +438,12 @@ pretty-prints the commit according to that shorthand. These are similar to the
 formats available with `--pretty=FOO` in many Git commands.
 
 Build it and run, and if you're using the same name in the example, you should
-see the subject line of the most recent commit in `origin/master` that you know
+see the subject line of the most recent commit in `origin/default` that you know
 about. Neat! Let's commit that as well.
 
 ----
 $ git add builtin/psuh.c
-$ git commit -sm "psuh: display the top of origin/master"
+$ git commit -sm "psuh: display the top of origin/default"
 ----
 
 [[add-documentation]]
@@ -780,13 +780,13 @@ by running `git branch`. If you didn't, now is a good time to move your new
 commits to their own branch.
 
 As mentioned briefly at the beginning of this document, we are basing our work
-on `master`, so go ahead and update as shown below, or using your preferred
+on `default`, so go ahead and update as shown below, or using your preferred
 workflow.
 
 ----
-$ git checkout master
+$ git checkout default
 $ git pull -r
-$ git rebase master psuh
+$ git rebase default psuh
 ----
 
 Finally, you're ready to push your new topic branch! (Due to our branch and
@@ -904,7 +904,7 @@ Sending emails with Git is a two-part process; before you can prepare the emails
 themselves, you'll need to prepare the patches. Luckily, this is pretty simple:
 
 ----
-$ git format-patch --cover-letter -o psuh/ master..psuh
+$ git format-patch --cover-letter -o psuh/ default..psuh
 ----
 
 The `--cover-letter` parameter tells `format-patch` to create a cover letter
@@ -915,8 +915,8 @@ The `-o psuh/` parameter tells `format-patch` to place the patch files into a
 directory. This is useful because `git send-email` can take a directory and
 send out all the patches from there.
 
-`master..psuh` tells `format-patch` to generate patches for the difference
-between `master` and `psuh`. It will make one patch file per commit. After you
+`default..psuh` tells `format-patch` to generate patches for the difference
+between `default` and `psuh`. It will make one patch file per commit. After you
 run, you can go have a look at each of the patches with your favorite text
 editor and make sure everything looks alright; however, it's not recommended to
 make code fixups via the patch file. It's a better idea to make the change the
@@ -1038,7 +1038,7 @@ similar.
 First, generate your v2 patches again:
 
 ----
-$ git format-patch -v2 --cover-letter -o psuh/ master..psuh
+$ git format-patch -v2 --cover-letter -o psuh/ default..psuh
 ----
 
 This will add your v2 patches, all named like `v2-000n-my-commit-subject.patch`,
@@ -1179,11 +1179,11 @@ look at the section below this one for some context.)
 [[after-approval]]
 === After Review Approval
 
-The Git project has four integration branches: `pu`, `next`, `master`, and
+The Git project has four integration branches: `pu`, `next`, `default`, and
 `maint`. Your change will be placed into `pu` fairly early on by the maintainer
 while it is still in the review process; from there, when it is ready for wider
 testing, it will be merged into `next`. Plenty of early testers use `next` and
-may report issues. Eventually, changes in `next` will make it to `master`,
+may report issues. Eventually, changes in `next` will make it to `default`,
 which is typically considered stable. Finally, when a new release is cut,
 `maint` is used to base bugfixes onto. As mentioned at the beginning of this
 document, you can read `Documents/SubmittingPatches` for some more info about
@@ -1214,4 +1214,4 @@ against the appropriate GitGitGadget/Git branch.
 
 If you're using `git send-email`, you can use it the same way as before, but you
 should generate your diffs from `<topic>..<mybranch>` and base your work on
-`<topic>` instead of `master`.
+`<topic>` instead of `default`.

Documentation/MyFirstObjectWalk.txt

@@ -24,10 +24,10 @@ revision walk is used for operations like `git log`.
 
 == Setting Up
 
-Create a new branch from `master`.
+Create a new branch from `default`.
 
 ----
-git checkout -b revwalk origin/master
+git checkout -b revwalk origin/default
 ----
 
 We'll put our fiddling into a new command. For fun, let's name it `git walken`.

Documentation/SubmittingPatches

@@ -13,31 +13,31 @@ In general, always base your work on the oldest branch that your
 change is relevant to.
 
 * A bugfix should be based on `maint` in general. If the bug is not
-  present in `maint`, base it on `master`. For a bug that's not yet
-  in `master`, find the topic that introduces the regression, and
+  present in `maint`, base it on `default`. For a bug that's not yet
+  in `default`, find the topic that introduces the regression, and
   base your work on the tip of the topic.
 
-* A new feature should be based on `master` in general. If the new
-  feature depends on a topic that is in `pu`, but not in `master`,
+* A new feature should be based on `default` in general. If the new
+  feature depends on a topic that is in `pu`, but not in `default`,
   base your work on the tip of that topic.
 
-* Corrections and enhancements to a topic not yet in `master` should
+* Corrections and enhancements to a topic not yet in `default` should
   be based on the tip of that topic. If the topic has not been merged
   to `next`, it's alright to add a note to squash minor corrections
   into the series.
 
 * In the exceptional case that a new feature depends on several topics
-  not in `master`, start working on `next` or `pu` privately and send
+  not in `default`, start working on `next` or `pu` privately and send
   out patches for discussion. Before the final merge, you may have to
-  wait until some of the dependent topics graduate to `master`, and
+  wait until some of the dependent topics graduate to `default`, and
   rebase your work.
 
 * Some parts of the system have dedicated maintainers with their own
   repositories (see the section "Subsystems" below).  Changes to
   these parts should be based on their trees.
 
 To find the tip of a topic branch, run `git log --first-parent
-master..pu` and look for the merge commit. The second parent of this
+default..pu` and look for the merge commit. The second parent of this
 commit is the tip of the topic branch.
 
 [[separate-commits]]
@@ -177,7 +177,7 @@ Please make sure your patch does not add commented out debugging code,
 or include any extra files which do not relate to what your patch
 is trying to achieve. Make sure to review
 your patch after generating it, to ensure accuracy.  Before
-sending out, please make sure it cleanly applies to the `master`
+sending out, please make sure it cleanly applies to the `default`
 branch head.  If you are preparing a work based on "next" branch,
 that is fine, but please mark it as such.
 
@@ -420,7 +420,7 @@ help you find out who they are.
   good.  Send it to the maintainer and cc the list.
 
 . A topic branch is created with the patch and is merged to `next`,
-  and cooked further and eventually graduates to `master`.
+  and cooked further and eventually graduates to `default`.
 
 In any time between the (2)-(3) cycle, the maintainer may pick it up
 from the list and queue it to `pu`, in order to make it easier for
@@ -431,11 +431,11 @@ their trees themselves.
 == Know the status of your patch after submission
 
 * You can use Git itself to find out when your patch is merged in
-  master. `git pull --rebase` will automatically skip already-applied
+  default. `git pull --rebase` will automatically skip already-applied
   patches, and will let you know. This works only if you rebase on top
   of the branch in which your patch has been merged (i.e. it will not
   tell you if your patch is merged in pu if you rebase on top of
-  master).
+  default).
 
 * Read the Git mailing list, the maintainer regularly posts messages
   entitled "What's cooking in git.git" and "What's in git.git" giving

Documentation/config/push.txt

@@ -37,9 +37,9 @@ This mode has become the default in Git 2.0.
 * `matching` - push all branches having the same name on both ends.
   This makes the repository you are pushing to remember the set of
   branches that will be pushed out (e.g. if you always push 'maint'
-  and 'master' there and no other branches, the repository you push
+  and 'default' there and no other branches, the repository you push
   to will have these two branches, and your local 'maint' and
-  'master' will be pushed there).
+  'default' will be pushed there).
 +
 To use this mode effectively, you have to make sure _all_ the
 branches you would push out are ready to be pushed out before

Documentation/config/transfer.txt

@@ -53,10 +53,10 @@ If you have multiple hideRefs values, later entries override earlier ones
 +
 If a namespace is in use, the namespace prefix is stripped from each
 reference before it is matched against `transfer.hiderefs` patterns.
-For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
-the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
-is omitted from the advertisements but `refs/heads/master` and
-`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
+For example, if `refs/heads/default` is specified in `transfer.hideRefs` and
+the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/default`
+is omitted from the advertisements but `refs/heads/default` and
+`refs/namespaces/bar/refs/heads/default` are still advertised as so-called
 "have" lines. In order to match refs before stripping, add a `^` in front of
 the ref name. If you combine `!` and `^`, `!` must be specified first.
 +

Documentation/doc-diff

@@ -4,9 +4,9 @@
 # Compared to a source diff, this can reveal mistakes in the formatting.
 # For example:
 #
-#   ./doc-diff origin/master HEAD
+#   ./doc-diff origin/default HEAD
 #
-# would show the differences introduced by a branch based on master.
+# would show the differences introduced by a branch based on default.
 
 OPTIONS_SPEC="\
 doc-diff [options] <from> <to> [-- <diff-options>]

Documentation/git-archimport.txt

@@ -45,7 +45,7 @@ archives that it imports, it is also possible to specify Git branch names
 manually.  To do so, write a Git branch name after each <archive/branch>
 parameter, separated by a colon.  This way, you can shorten the Arch
 branch names and convert Arch jargon to Git jargon, for example mapping a
-"PROJECT{litdd}devo{litdd}VERSION" branch to "master".
+"PROJECT{litdd}devo{litdd}VERSION" branch to "default".
 
 Associating multiple Arch branches to one Git branch is possible; the
 result will make the most sense only if no commits are made to the first

Documentation/git-bisect-lk2009.txt

@@ -294,7 +294,7 @@ the branch we were in before we started bisecting:
 $ git bisect reset
 Checking out files: 100% (21549/21549), done.
 Previous HEAD position was 2ddcca3... Linux 2.6.26-rc1
-Switched to branch 'master'
+Switched to branch 'default'
 -------------
 
 Driving a bisection automatically
@@ -1229,7 +1229,7 @@ message or the author. And it can also be used instead of git "grafts"
 to link a repository with another old repository.
 
 In fact it's this last feature that "sold" it to the Git community, so
-it is now in the "master" branch of Git's Git repository and it should
+it is now in the "default" branch of Git's Git repository and it should
 be released in Git 1.6.5 in October or November 2009.
 
 One problem with "git replace" is that currently it stores all the

Documentation/git-branch.txt

@@ -331,7 +331,7 @@ $ git branch -D test                                    <2>
 <1> Delete the remote-tracking branches "todo", "html" and "man". The next
     'fetch' or 'pull' will create them again unless you configure them not to.
     See linkgit:git-fetch[1].
-<2> Delete the "test" branch even if the "master" branch (or whichever branch
+<2> Delete the "test" branch even if the "default" branch (or whichever branch
     is currently checked out) does not have all commits from the test branch.
 
 Listing branches from a specific remote::

Documentation/git-bundle.txt

@@ -66,8 +66,8 @@ unbundle <file>::
 	A list of arguments, acceptable to 'git rev-parse' and
 	'git rev-list' (and containing a named ref, see SPECIFYING REFERENCES
 	below), that specifies the specific objects and references
-	to transport.  For example, `master~10..master` causes the
-	current master reference to be packaged along with all objects
+	to transport.  For example, `default~10..default` causes the
+	current default reference to be packaged along with all objects
 	added since its 10th ancestor commit.  There is no explicit
 	limit to the number of references and objects that may be
 	packaged.
@@ -112,12 +112,12 @@ SPECIFYING REFERENCES
 
 'git bundle' will only package references that are shown by
 'git show-ref': this includes heads, tags, and remote heads.  References
-such as `master~1` cannot be packaged, but are perfectly suitable for
+such as `default~1` cannot be packaged, but are perfectly suitable for
 defining the basis.  More than one reference may be packaged, and more
 than one basis can be specified.  The objects packaged are those not
 contained in the union of the given bases.  Each basis can be
-specified explicitly (e.g. `^master~10`), or implicitly (e.g.
-`master~10..master`, `--since=10.days.ago master`).
+specified explicitly (e.g. `^default~10`), or implicitly (e.g.
+`default~10..default`, `--since=10.days.ago default`).
 
 It is very important that the basis used be held by the destination.
 It is okay to err on the side of caution, causing the bundle file
@@ -139,7 +139,7 @@ Assume you want to transfer the history from a repository R1 on machine A
 to another repository R2 on machine B.
 For whatever reason, direct connection between A and B is not allowed,
 but we can move data from A to B via some mechanism (CD, email, etc.).
-We want to update R2 with development made on the branch master in R1.
+We want to update R2 with development made on the branch default in R1.
 
 To bootstrap the process, you can first create a bundle that does not have
 any basis. You can use a tag to remember up to what commit you last
@@ -148,16 +148,16 @@ with an incremental bundle:
 
 ----------------
 machineA$ cd R1
-machineA$ git bundle create file.bundle master
-machineA$ git tag -f lastR2bundle master
+machineA$ git bundle create file.bundle default
+machineA$ git tag -f lastR2bundle default
 ----------------
 
 Then you transfer file.bundle to the target machine B. Because this
 bundle does not require any existing object to be extracted, you can
 create a new repository on machine B by cloning from it:
 
 ----------------
-machineB$ git clone -b master /home/me/tmp/file.bundle R2
+machineB$ git clone -b default /home/me/tmp/file.bundle R2
 ----------------
 
 This will define a remote called "origin" in the resulting repository that
@@ -179,8 +179,8 @@ incremental bundle to update the other repository:
 
 ----------------
 machineA$ cd R1
-machineA$ git bundle create file.bundle lastR2bundle..master
-machineA$ git tag -f lastR2bundle master
+machineA$ git bundle create file.bundle lastR2bundle..default
+machineA$ git tag -f lastR2bundle default
 ----------------
 
 You then transfer the bundle to the other machine to replace
@@ -201,19 +201,19 @@ the linkgit:git-log[1] command. Here are more examples:
 You can use a tag that is present in both:
 
 ----------------
-$ git bundle create mybundle v1.0.0..master
+$ git bundle create mybundle v1.0.0..default
 ----------------
 
 You can use a basis based on time:
 
 ----------------
-$ git bundle create mybundle --since=10.days master
+$ git bundle create mybundle --since=10.days default
 ----------------
 
 You can use the number of commits:
 
 ----------------
-$ git bundle create mybundle -10 master
+$ git bundle create mybundle -10 default
 ----------------
 
 You can run `git-bundle verify` to see if you can extract from a bundle
@@ -231,7 +231,7 @@ regular repository which it fetches or pulls from. You can, for example, map
 references when fetching:
 
 ----------------
-$ git fetch mybundle master:localRef
+$ git fetch mybundle default:localRef
 ----------------
 
 You can also see what references it offers: