mirror of https://github.com/zulip/zulip.git
docs: Fix Git capitalization.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
parent
f244c2eca4
commit
503127c2e9
|
@ -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
|
||||||
|
|
|
@ -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.
|
||||||
|
|
||||||
|
|
|
@ -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`.
|
||||||
|
|
||||||
|
|
|
@ -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
|
||||||
|
|
|
@ -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:
|
||||||
|
|
|
@ -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
|
||||||
|
|
|
@ -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
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue