docs: Fix Git capitalization.

Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
Anders Kaseorg 2022-02-28 13:15:06 -08:00 committed by Tim Abbott
parent f244c2eca4
commit 503127c2e9
7 changed files with 16 additions and 16 deletions

View File

@ -31,7 +31,7 @@ We also highly recommend the following:
## Get a graphical client ## Get a graphical client
Even if you're comfortable using git on the command line, having a graphical Even if you're comfortable using Git on the command line, having a graphical
client can be useful for viewing your repository. This is especially true client can be useful for viewing your repository. This is especially true
when doing complicated rebases and similar operations because you can check when doing complicated rebases and similar operations because you can check
the state of your repository after each command to see what changed. If the state of your repository after each command to see what changed. If

View File

@ -4,7 +4,7 @@ Git is a powerful yet complex version control system. Even for contributors
experienced at using version control, it can be confusing. The good news is experienced at using version control, it can be confusing. The good news is
that nearly all Git actions add information to the Git database, rather than that nearly all Git actions add information to the Git database, rather than
removing it. As such, it's hard to make Git perform actions that you can't removing it. As such, it's hard to make Git perform actions that you can't
undo. However, git can't undo what it doesn't know about, so it's a good undo. However, Git can't undo what it doesn't know about, so it's a good
practice to frequently commit your changes and frequently push your commits to practice to frequently commit your changes and frequently push your commits to
your remote repository. your remote repository.
@ -59,7 +59,7 @@ e5f8211 HEAD@{0}: pull upstream main: Merge made by the 'recursive' strategy.
13bea0e HEAD@{1}: commit: test commit for docs. 13bea0e HEAD@{1}: commit: test commit for docs.
``` ```
Reflog output will be long. The most recent git refs will be listed at the top. Reflog output will be long. The most recent Git refs will be listed at the top.
In the example above `e5f8211 HEAD@{0}:` is the merge commit made automatically In the example above `e5f8211 HEAD@{0}:` is the merge commit made automatically
by `git pull` and `13bea0e HEAD@{1}:` is the last commit I made before running by `git pull` and `13bea0e HEAD@{1}:` is the last commit I made before running
`git pull`, the commit that I want to rollback to. `git pull`, the commit that I want to rollback to.
@ -81,7 +81,7 @@ committed, use `git reset --merge <commit>` instead.
::: :::
You can also use the relative reflog `HEAD@{1}` instead of the commit hash, You can also use the relative reflog `HEAD@{1}` instead of the commit hash,
just keep in mind that this changes as you run git commands. just keep in mind that this changes as you run Git commands.
Now when you look at the output of `git reflog`, you should see that the tip of your branch points to your Now when you look at the output of `git reflog`, you should see that the tip of your branch points to your
last commit `13bea0e` before the merge: last commit `13bea0e` before the merge:
@ -145,10 +145,10 @@ $ git cherry-pick 67aea58
create mode 100644 test4.txt create mode 100644 test4.txt
``` ```
## Recover from a git rebase failure ## Recover from a `git rebase` failure
One situation in which `git rebase` will fail and require you to intervene is One situation in which `git rebase` will fail and require you to intervene is
when your change, which git will try to re-apply on top of new commits from when your change, which Git will try to re-apply on top of new commits from
which ever branch you are rebasing on top of, is to code that has been changed which ever branch you are rebasing on top of, is to code that has been changed
by those new commits. by those new commits.

View File

@ -3,7 +3,7 @@
## Know what branch you're working on ## Know what branch you're working on
When using Git, it's important to know which branch you currently have checked When using Git, it's important to know which branch you currently have checked
out because most git commands implicitly operate on the current branch. You can out because most Git commands implicitly operate on the current branch. You can
determine the currently checked out branch several ways. determine the currently checked out branch several ways.
One way is with [git status][gitbook-git-status]: One way is with [git status][gitbook-git-status]:
@ -44,7 +44,7 @@ You can also configure [Bash][gitbook-other-envs-bash] and
You'll want to [keep your fork][github-help-sync-fork] up-to-date with changes You'll want to [keep your fork][github-help-sync-fork] up-to-date with changes
from Zulip's main repositories. from Zulip's main repositories.
**Note about git pull**: You might be used to using `git pull` on other **Note about `git pull`**: You might be used to using `git pull` on other
projects. With Zulip, because we don't use merge commits, you'll want to avoid projects. With Zulip, because we don't use merge commits, you'll want to avoid
it. Rather than using `git pull`, which by default is a shortcut for it. Rather than using `git pull`, which by default is a shortcut for
`git fetch && git merge FETCH_HEAD` ([docs][gitbook-git-pull]), you `git fetch && git merge FETCH_HEAD` ([docs][gitbook-git-pull]), you
@ -164,7 +164,7 @@ Untracked files:
nothing added to commit but untracked files present (use "git add" to track) nothing added to commit but untracked files present (use "git add" to track)
``` ```
### Stage additions with git add ### Stage additions with `git add`
To add changes to your staging area, use `git add <filename>`. Because To add changes to your staging area, use `git add <filename>`. Because
`git add` is all about staging the changes you want to commit, you use `git add` is all about staging the changes you want to commit, you use
@ -212,7 +212,7 @@ Untracked files:
nothing added to commit but untracked files present (use "git add" to track) nothing added to commit but untracked files present (use "git add" to track)
``` ```
### Stage deletions with git rm ### Stage deletions with `git rm`
To remove existing files from your repository, use `git rm` To remove existing files from your repository, use `git rm`
([documentation][gitbook-rm]). This command can either stage the file for ([documentation][gitbook-rm]). This command can either stage the file for
@ -264,7 +264,7 @@ $ git reset HEAD test2.txt
Unfortunately, you can't restore a file deleted with `git rm` if you didn't use Unfortunately, you can't restore a file deleted with `git rm` if you didn't use
the `--cache` option. However, `git rm` only deletes files it knows about. the `--cache` option. However, `git rm` only deletes files it knows about.
Files you have never added to git won't be deleted. Files you have never added to Git won't be deleted.
## Commit changes ## Commit changes
@ -349,7 +349,7 @@ To git@github.com:christi3k/zulip.git
* [new branch] issue-demo -> issue-demo * [new branch] issue-demo -> issue-demo
``` ```
If you want to see what git will do without actually performing the push, add If you want to see what Git will do without actually performing the push, add
the `-n` (dry-run) option: `git push -n origin <branch-name>`. If everything the `-n` (dry-run) option: `git push -n origin <branch-name>`. If everything
looks good, re-run the push command without `-n`. looks good, re-run the push command without `-n`.

View File

@ -72,7 +72,7 @@ you a lot of time, by automatically detecting linter errors as you
make them. make them.
::: :::
**Note:** The linters only check files that git tracks. Remember to `git add` **Note:** The linters only check files that Git tracks. Remember to `git add`
new files before running lint checks. new files before running lint checks.
Our linting tools generally support the ability to lint files Our linting tools generally support the ability to lint files

View File

@ -504,7 +504,7 @@ unfortunately give up some type safety by falling back to
## Troubleshooting advice ## Troubleshooting advice
All of our linters, including mypy, are designed to only check files All of our linters, including mypy, are designed to only check files
that have been added in git (this is by design, since it means you that have been added in Git (this is by design, since it means you
have untracked files in your Zulip checkout safely). So if you get a have untracked files in your Zulip checkout safely). So if you get a
`mypy` error like this after adding a new file that is referenced by `mypy` error like this after adding a new file that is referenced by
the existing codebase: the existing codebase:

View File

@ -93,7 +93,7 @@ class BaseDocumentationSpider(scrapy.Spider):
if url.startswith(ZULIP_SERVER_GITHUB_FILE_URL_PREFIX) or url.startswith( if url.startswith(ZULIP_SERVER_GITHUB_FILE_URL_PREFIX) or url.startswith(
ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX
): ):
# We can verify these links directly in the local git repo without making any requests to GitHub servers. # We can verify these links directly in the local Git repo without making any requests to GitHub servers.
return False return False
if "github.com/zulip" in url: if "github.com/zulip" in url:
# We want to check these links but due to rate limiting from GitHub, these checks often # We want to check these links but due to rate limiting from GitHub, these checks often

View File

@ -166,7 +166,7 @@ def need_to_run_build_timezone_data() -> bool:
def need_to_run_compilemessages() -> bool: def need_to_run_compilemessages() -> bool:
if not os.path.exists("locale/language_name_map.json"): if not os.path.exists("locale/language_name_map.json"):
# User may have cleaned their git checkout. # User may have cleaned their Git checkout.
print("Need to run compilemessages due to missing language_name_map.json") print("Need to run compilemessages due to missing language_name_map.json")
return True return True