contributor docs: Rename "Version Control" to "Commit Discipline".

docs/contributing/code-reviewing.md

@@ -150,7 +150,7 @@ The following review steps apply to the majority of PRs.
    about commit structure in Zulip.
 
 2. Does each commit have a **clear commit message**? Check for content, format,
-   spelling and grammar. See the [Zulip version control][commit-messages]
+   spelling and grammar. See the [Zulip commit discipline][commit-messages]
    documentation for details on what we look for.
 
 You should also go through any of the following checks that are applicable:
@@ -398,8 +398,8 @@ We also recommend the following resources on code reviews.
 - [Zulip code of conduct](../code-of-conduct.md)
 
 [code-style]: code-style.md
-[commit-discipline]: version-control.md#commit-discipline
-[commit-messages]: version-control.md#commit-messages
+[commit-discipline]: commit-discipline.md
+[commit-messages]: commit-discipline.md#commit-messages
 [test-writing]: ../testing/testing.md
 [backend-testing]: ../testing/testing-with-django.md
 [frontend-testing]: ../testing/testing-with-node.md

docs/contributing/commit-discipline.md

@@ -1,6 +1,4 @@
-# Version control
-
-## Commit discipline
+# Commit discipline
 
 We follow the Git project's own commit discipline practice of "Each
 commit is a minimal coherent idea". This discipline takes a bit of work,

docs/contributing/index.md

@@ -9,7 +9,7 @@ contributing
 ../code-of-conduct
 asking-great-questions
 design-discussions
-version-control
+commit-discipline
 code-style
 reviewable-prs
 code-reviewing

docs/contributing/reviewable-prs.md

@@ -69,5 +69,5 @@ Here is some advice on how to proceed:
   Whenever possible, find chunks of complexity that you can separate from the
   rest of the project.
 
-See our [commit discipline guide](../contributing/version-control.md) for
+See our [commit discipline guide](../contributing/commit-discipline.md) for
 more details on writing reviewable commits.

docs/git/overview.md

@@ -63,8 +63,8 @@ Git workflow, or if you'd like a Git refresher.
 [continuous-integration]: ../testing/continuous-integration.md
 [zulip-git-guide-fork-ci]: cloning.md#step-3-configure-continuous-integration-for-your-fork
 [zulip-rtd-code-style]: ../contributing/code-style.md
-[zulip-rtd-commit-discipline]: ../contributing/version-control.md#commit-discipline
-[zulip-rtd-commit-messages]: ../contributing/version-control.md#commit-messages
+[zulip-rtd-commit-discipline]: ../contributing/commit-discipline.md
+[zulip-rtd-commit-messages]: ../contributing/commit-discipline.md
 [zulip-rtd-dev-overview]: ../development/overview.md
 [zulip-rtd-lint-tools]: ../contributing/code-style.md#lint-tools
 [zulip-rtd-mypy]: ../testing/mypy.md

docs/git/using.md

@@ -453,5 +453,5 @@ complicated rebase.
 [how-git-is-different]: the-git-difference.md
 [self-multiple-computers]: troubleshooting.md#working-from-multiple-computers
 [zulip-git-guide-up-to-date]: #keep-your-fork-up-to-date
-[zulip-rtd-commit-discipline]: ../contributing/version-control.md#commit-discipline
-[zulip-rtd-commit-messages]: ../contributing/version-control.md#commit-messages
+[zulip-rtd-commit-discipline]: ../contributing/commit-discipline.md
+[zulip-rtd-commit-messages]: ../contributing/commit-discipline.md

docs/outreach/apply.md

@@ -34,7 +34,7 @@ the following:
    venture, and effective communication is key to making it successful. Learn
    how to [ask great questions](../contributing/asking-great-questions.md), and
    explain your decisions clearly [in your commit
-   messages](../contributing/version-control.md#commit-discipline) and [on your
+   messages](../contributing/commit-discipline.md#commit-messages) and [on your
    pull requests](../contributing/reviewable-prs.md).
 
 3. **Improvement in response to feedback.** Don't worry if you make
@@ -92,9 +92,9 @@ As you are getting started on your first pull request:
   [graphical Git client](../git/setup.md#get-a-graphical-client).
 
 - Construct [coherent, mergeable
-  commits](../contributing/version-control.md#commit-discipline), with clear
+  commits](../contributing/commit-discipline.md), with clear
   commit messages that follow the [Zulip commit style
-  guide](../contributing/version-control.md#commit-messages). More broadly, clear
+  guide](../contributing/commit-discipline.md). More broadly, clear
   communication on your pull request will make your work stand out.
 
 - Carefully follow our [guide to reviewing your own

docs/outreach/mentoring.md

@@ -51,7 +51,7 @@ will depend on what your mentee needs. It might be any combination of:
 - Helping your mentee figure out how to test their changes.
 
 - Helping your mentee break their PRs into [coherent
-  commits](../contributing/version-control.md#commit-discipline).
+  commits](../contributing/commit-discipline.md).
 
 - Doing [code review](../contributing/code-reviewing.md) of your
   mentee's work.

templates/zerver/api/incoming-webhooks-walkthrough.md

@@ -476,7 +476,7 @@ request:
    https://zulip.readthedocs.io/en/latest/contributing/code-style.html) and take a look
    through your code to double-check that you've followed Zulip's guidelines.
 3. Take a look at your Git history to ensure your commits have been clear and
-   logical (see [Version control](
+   logical (see [Commit discipline](
    https://zulip.readthedocs.io/en/latest/contributing/version-control.html) for tips). If not,
    consider revising them with `git rebase --interactive`. For most incoming webhooks,
    you'll want to squash your changes into a single commit and include a good,