about summary refs log tree commit diff
path: root/third_party/git/Documentation/gitfaq.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/git/Documentation/gitfaq.txt')
-rw-r--r--third_party/git/Documentation/gitfaq.txt441
1 files changed, 0 insertions, 441 deletions
diff --git a/third_party/git/Documentation/gitfaq.txt b/third_party/git/Documentation/gitfaq.txt
deleted file mode 100644
index afdaeab8503c..000000000000
--- a/third_party/git/Documentation/gitfaq.txt
+++ /dev/null
@@ -1,441 +0,0 @@
-gitfaq(7)
-=========
-
-NAME
-----
-gitfaq - Frequently asked questions about using Git
-
-SYNOPSIS
---------
-gitfaq
-
-DESCRIPTION
------------
-
-The examples in this FAQ assume a standard POSIX shell, like `bash` or `dash`,
-and a user, A U Thor, who has the account `author` on the hosting provider
-`git.example.org`.
-
-Configuration
--------------
-
-[[user-name]]
-What should I put in `user.name`?::
-	You should put your personal name, generally a form using a given name
-	and family name.  For example, the current maintainer of Git uses "Junio
-	C Hamano".  This will be the name portion that is stored in every commit
-	you make.
-+
-This configuration doesn't have any effect on authenticating to remote services;
-for that, see `credential.username` in linkgit:git-config[1].
-
-[[http-postbuffer]]
-What does `http.postBuffer` really do?::
-	This option changes the size of the buffer that Git uses when pushing
-	data to a remote over HTTP or HTTPS.  If the data is larger than this
-	size, libcurl, which handles the HTTP support for Git, will use chunked
-	transfer encoding since it isn't known ahead of time what the size of
-	the pushed data will be.
-+
-Leaving this value at the default size is fine unless you know that either the
-remote server or a proxy in the middle doesn't support HTTP/1.1 (which
-introduced the chunked transfer encoding) or is known to be broken with chunked
-data.  This is often (erroneously) suggested as a solution for generic push
-problems, but since almost every server and proxy supports at least HTTP/1.1,
-raising this value usually doesn't solve most push problems.  A server or proxy
-that didn't correctly support HTTP/1.1 and chunked transfer encoding wouldn't be
-that useful on the Internet today, since it would break lots of traffic.
-+
-Note that increasing this value will increase the memory used on every relevant
-push that Git does over HTTP or HTTPS, since the entire buffer is allocated
-regardless of whether or not it is all used.  Thus, it's best to leave it at the
-default unless you are sure you need a different value.
-
-[[configure-editor]]
-How do I configure a different editor?::
-	If you haven't specified an editor specifically for Git, it will by default
-	use the editor you've configured using the `VISUAL` or `EDITOR` environment
-	variables, or if neither is specified, the system default (which is usually
-	`vi`).  Since some people find `vi` difficult to use or prefer a different
-	editor, it may be desirable to change the editor used.
-+
-If you want to configure a general editor for most programs which need one, you
-can edit your shell configuration (e.g., `~/.bashrc` or `~/.zshenv`) to contain
-a line setting the `EDITOR` or `VISUAL` environment variable to an appropriate
-value.  For example, if you prefer the editor `nano`, then you could write the
-following:
-+
-----
-export VISUAL=nano
-----
-+
-If you want to configure an editor specifically for Git, you can either set the
-`core.editor` configuration value or the `GIT_EDITOR` environment variable.  You
-can see linkgit:git-var[1] for details on the order in which these options are
-consulted.
-+
-Note that in all cases, the editor value will be passed to the shell, so any
-arguments containing spaces should be appropriately quoted.  Additionally, if
-your editor normally detaches from the terminal when invoked, you should specify
-it with an argument that makes it not do that, or else Git will not see any
-changes.  An example of a configuration addressing both of these issues on
-Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`,
-which quotes the filename with spaces and specifies the `--nofork` option to
-avoid backgrounding the process.
-
-Credentials
------------
-
-[[http-credentials]]
-How do I specify my credentials when pushing over HTTP?::
-	The easiest way to do this is to use a credential helper via the
-	`credential.helper` configuration.  Most systems provide a standard
-	choice to integrate with the system credential manager.  For example,
-	Git for Windows provides the `wincred` credential manager, macOS has the
-	`osxkeychain` credential manager, and Unix systems with a standard
-	desktop environment can use the `libsecret` credential manager.  All of
-	these store credentials in an encrypted store to keep your passwords or
-	tokens secure.
-+
-In addition, you can use the `store` credential manager which stores in a file
-in your home directory, or the `cache` credential manager, which does not
-permanently store your credentials, but does prevent you from being prompted for
-them for a certain period of time.
-+
-You can also just enter your password when prompted.  While it is possible to
-place the password (which must be percent-encoded) in the URL, this is not
-particularly secure and can lead to accidental exposure of credentials, so it is
-not recommended.
-
-[[http-credentials-environment]]
-How do I read a password or token from an environment variable?::
-	The `credential.helper` configuration option can also take an arbitrary
-	shell command that produces the credential protocol on standard output.
-	This is useful when passing credentials into a container, for example.
-+
-Such a shell command can be specified by starting the option value with an
-exclamation point.  If your password or token were stored in the `GIT_TOKEN`,
-you could run the following command to set your credential helper:
-+
-----
-$ git config credential.helper \
-	'!f() { echo username=author; echo "password=$GIT_TOKEN"; };f'
-----
-
-[[http-reset-credentials]]
-How do I change the password or token I've saved in my credential manager?::
-	Usually, if the password or token is invalid, Git will erase it and
-	prompt for a new one.  However, there are times when this doesn't always
-	happen.  To change the password or token, you can erase the existing
-	credentials and then Git will prompt for new ones.  To erase
-	credentials, use a syntax like the following (substituting your username
-	and the hostname):
-+
-----
-$ echo url=https://author@git.example.org | git credential reject
-----
-
-[[multiple-accounts-http]]
-How do I use multiple accounts with the same hosting provider using HTTP?::
-	Usually the easiest way to distinguish between these accounts is to use
-	the username in the URL.  For example, if you have the accounts `author`
-	and `committer` on `git.example.org`, you can use the URLs
-	https://author@git.example.org/org1/project1.git and
-	https://committer@git.example.org/org2/project2.git.  This way, when you
-	use a credential helper, it will automatically try to look up the
-	correct credentials for your account.  If you already have a remote set
-	up, you can change the URL with something like `git remote set-url
-	origin https://author@git.example.org/org1/project1.git` (see
-	linkgit:git-remote[1] for details).
-
-[[multiple-accounts-ssh]]
-How do I use multiple accounts with the same hosting provider using SSH?::
-	With most hosting providers that support SSH, a single key pair uniquely
-	identifies a user.  Therefore, to use multiple accounts, it's necessary
-	to create a key pair for each account.  If you're using a reasonably
-	modern OpenSSH version, you can create a new key pair with something
-	like `ssh-keygen -t ed25519 -f ~/.ssh/id_committer`.  You can then
-	register the public key (in this case, `~/.ssh/id_committer.pub`; note
-	the `.pub`) with the hosting provider.
-+
-Most hosting providers use a single SSH account for pushing; that is, all users
-push to the `git` account (e.g., `git@git.example.org`).  If that's the case for
-your provider, you can set up multiple aliases in SSH to make it clear which key
-pair to use.  For example, you could write something like the following in
-`~/.ssh/config`, substituting the proper private key file:
-+
-----
-# This is the account for author on git.example.org.
-Host example_author
-	HostName git.example.org
-	User git
-	# This is the key pair registered for author with git.example.org.
-	IdentityFile ~/.ssh/id_author
-	IdentitiesOnly yes
-# This is the account for committer on git.example.org.
-Host example_committer
-	HostName git.example.org
-	User git
-	# This is the key pair registered for committer with git.example.org.
-	IdentityFile ~/.ssh/id_committer
-	IdentitiesOnly yes
-----
-+
-Then, you can adjust your push URL to use `git@example_author` or
-`git@example_committer` instead of `git@example.org` (e.g., `git remote set-url
-git@example_author:org1/project1.git`).
-
-Common Issues
--------------
-
-[[last-commit-amend]]
-I've made a mistake in the last commit.  How do I change it?::
-	You can make the appropriate change to your working tree, run `git add
-	<file>` or `git rm <file>`, as appropriate, to stage it, and then `git
-	commit --amend`.  Your change will be included in the commit, and you'll
-	be prompted to edit the commit message again; if you wish to use the
-	original message verbatim, you can use the `--no-edit` option to `git
-	commit` in addition, or just save and quit when your editor opens.
-
-[[undo-previous-change]]
-I've made a change with a bug and it's been included in the main branch.  How should I undo it?::
-	The usual way to deal with this is to use `git revert`.  This preserves
-	the history that the original change was made and was a valuable
-	contribution, but also introduces a new commit that undoes those changes
-	because the original had a problem.  The commit message of the revert
-	indicates the commit which was reverted and is usually edited to include
-	an explanation as to why the revert was made.
-
-[[ignore-tracked-files]]
-How do I ignore changes to a tracked file?::
-	Git doesn't provide a way to do this.  The reason is that if Git needs
-	to overwrite this file, such as during a checkout, it doesn't know
-	whether the changes to the file are precious and should be kept, or
-	whether they are irrelevant and can safely be destroyed.  Therefore, it
-	has to take the safe route and always preserve them.
-+
-It's tempting to try to use certain features of `git update-index`, namely the
-assume-unchanged and skip-worktree bits, but these don't work properly for this
-purpose and shouldn't be used this way.
-+
-If your goal is to modify a configuration file, it can often be helpful to have
-a file checked into the repository which is a template or set of defaults which
-can then be copied alongside and modified as appropriate.  This second, modified
-file is usually ignored to prevent accidentally committing it.
-
-[[files-in-gitignore-are-tracked]]
-I asked Git to ignore various files, yet they are still tracked::
-	A `gitignore` file ensures that certain file(s) which are not
-	tracked by Git remain untracked.  However, sometimes particular
-	file(s) may have been tracked before adding them into the
-	`.gitignore`, hence they still remain tracked.  To untrack and
-	ignore files/patterns, use `git rm --cached <file/pattern>`
-	and add a pattern to `.gitignore` that matches the <file>.
-	See linkgit:gitignore[5] for details.
-
-[[fetching-and-pulling]]
-How do I know if I want to do a fetch or a pull?::
-	A fetch stores a copy of the latest changes from the remote
-	repository, without modifying the working tree or current branch.
-	You can then at your leisure inspect, merge, rebase on top of, or
-	ignore the upstream changes.  A pull consists of a fetch followed
-	immediately by either a merge or rebase.  See linkgit:git-pull[1].
-
-Merging and Rebasing
---------------------
-
-[[long-running-squash-merge]]
-What kinds of problems can occur when merging long-lived branches with squash merges?::
-	In general, there are a variety of problems that can occur when using squash
-	merges to merge two branches multiple times.  These can include seeing extra
-	commits in `git log` output, with a GUI, or when using the `...` notation to
-	express a range, as well as the possibility of needing to re-resolve conflicts
-	again and again.
-+
-When Git does a normal merge between two branches, it considers exactly three
-points: the two branches and a third commit, called the _merge base_, which is
-usually the common ancestor of the commits.  The result of the merge is the sum
-of the changes between the merge base and each head.  When you merge two
-branches with a regular merge commit, this results in a new commit which will
-end up as a merge base when they're merged again, because there is now a new
-common ancestor.  Git doesn't have to consider changes that occurred before the
-merge base, so you don't have to re-resolve any conflicts you resolved before.
-+
-When you perform a squash merge, a merge commit isn't created; instead, the
-changes from one side are applied as a regular commit to the other side.  This
-means that the merge base for these branches won't have changed, and so when Git
-goes to perform its next merge, it considers all of the changes that it
-considered the last time plus the new changes.  That means any conflicts may
-need to be re-resolved.  Similarly, anything using the `...` notation in `git
-diff`, `git log`, or a GUI will result in showing all of the changes since the
-original merge base.
-+
-As a consequence, if you want to merge two long-lived branches repeatedly, it's
-best to always use a regular merge commit.
-
-[[merge-two-revert-one]]
-If I make a change on two branches but revert it on one, why does the merge of those branches include the change?::
-	By default, when Git does a merge, it uses a strategy called the recursive
-	strategy, which does a fancy three-way merge.  In such a case, when Git
-	performs the merge, it considers exactly three points: the two heads and a
-	third point, called the _merge base_, which is usually the common ancestor of
-	those commits.  Git does not consider the history or the individual commits
-	that have happened on those branches at all.
-+
-As a result, if both sides have a change and one side has reverted that change,
-the result is to include the change.  This is because the code has changed on
-one side and there is no net change on the other, and in this scenario, Git
-adopts the change.
-+
-If this is a problem for you, you can do a rebase instead, rebasing the branch
-with the revert onto the other branch.  A rebase in this scenario will revert
-the change, because a rebase applies each individual commit, including the
-revert.  Note that rebases rewrite history, so you should avoid rebasing
-published branches unless you're sure you're comfortable with that.  See the
-NOTES section in linkgit:git-rebase[1] for more details.
-
-Hooks
------
-
-[[restrict-with-hooks]]
-How do I use hooks to prevent users from making certain changes?::
-	The only safe place to make these changes is on the remote repository
-	(i.e., the Git server), usually in the `pre-receive` hook or in a
-	continuous integration (CI) system.  These are the locations in which
-	policy can be enforced effectively.
-+
-It's common to try to use `pre-commit` hooks (or, for commit messages,
-`commit-msg` hooks) to check these things, which is great if you're working as a
-solo developer and want the tooling to help you.  However, using hooks on a
-developer machine is not effective as a policy control because a user can bypass
-these hooks with `--no-verify` without being noticed (among various other ways).
-Git assumes that the user is in control of their local repositories and doesn't
-try to prevent this or tattle on the user.
-+
-In addition, some advanced users find `pre-commit` hooks to be an impediment to
-workflows that use temporary commits to stage work in progress or that create
-fixup commits, so it's better to push these kinds of checks to the server
-anyway.
-
-Cross-Platform Issues
----------------------
-
-[[windows-text-binary]]
-I'm on Windows and my text files are detected as binary.::
-	Git works best when you store text files as UTF-8.  Many programs on
-	Windows support UTF-8, but some do not and only use the little-endian
-	UTF-16 format, which Git detects as binary.  If you can't use UTF-8 with
-	your programs, you can specify a working tree encoding that indicates
-	which encoding your files should be checked out with, while still
-	storing these files as UTF-8 in the repository.  This allows tools like
-	linkgit:git-diff[1] to work as expected, while still allowing your tools
-	to work.
-+
-To do so, you can specify a linkgit:gitattributes[5] pattern with the
-`working-tree-encoding` attribute.  For example, the following pattern sets all
-C files to use UTF-16LE-BOM, which is a common encoding on Windows:
-+
-----
-*.c	working-tree-encoding=UTF-16LE-BOM
-----
-+
-You will need to run `git add --renormalize` to have this take effect.  Note
-that if you are making these changes on a project that is used across platforms,
-you'll probably want to make it in a per-user configuration file or in the one
-in `$GIT_DIR/info/attributes`, since making it in a `.gitattributes` file in the
-repository will apply to all users of the repository.
-+
-See the following entry for information about normalizing line endings as well,
-and see linkgit:gitattributes[5] for more information about attribute files.
-
-[[windows-diff-control-m]]
-I'm on Windows and git diff shows my files as having a `^M` at the end.::
-	By default, Git expects files to be stored with Unix line endings.  As such,
-	the carriage return (`^M`) that is part of a Windows line ending is shown
-	because it is considered to be trailing whitespace.  Git defaults to showing
-	trailing whitespace only on new lines, not existing ones.
-+
-You can store the files in the repository with Unix line endings and convert
-them automatically to your platform's line endings.  To do that, set the
-configuration option `core.eol` to `native` and see the following entry for
-information about how to configure files as text or binary.
-+
-You can also control this behavior with the `core.whitespace` setting if you
-don't wish to remove the carriage returns from your line endings.
-
-[[always-modified-files-case]]
-Why do I have a file that's always modified?::
-	Internally, Git always stores file names as sequences of bytes and doesn't
-	perform any encoding or case folding.  However, Windows and macOS by default
-	both perform case folding on file names.  As a result, it's possible to end up
-	with multiple files or directories whose names differ only in case.  Git can
-	handle this just fine, but the file system can store only one of these files,
-	so when Git reads the other file to see its contents, it looks modified.
-+
-It's best to remove one of the files such that you only have one file.  You can
-do this with commands like the following (assuming two files `AFile.txt` and
-`afile.txt`) on an otherwise clean working tree:
-+
-----
-$ git rm --cached AFile.txt
-$ git commit -m 'Remove files conflicting in case'
-$ git checkout .
-----
-+
-This avoids touching the disk, but removes the additional file.  Your project
-may prefer to adopt a naming convention, such as all-lowercase names, to avoid
-this problem from occurring again; such a convention can be checked using a
-`pre-receive` hook or as part of a continuous integration (CI) system.
-+
-It is also possible for perpetually modified files to occur on any platform if a
-smudge or clean filter is in use on your system but a file was previously
-committed without running the smudge or clean filter.  To fix this, run the
-following on an otherwise clean working tree:
-+
-----
-$ git add --renormalize .
-----
-
-[[recommended-storage-settings]]
-What's the recommended way to store files in Git?::
-	While Git can store and handle any file of any type, there are some
-	settings that work better than others.  In general, we recommend that
-	text files be stored in UTF-8 without a byte-order mark (BOM) with LF
-	(Unix-style) endings.  We also recommend the use of UTF-8 (again,
-	without BOM) in commit messages.  These are the settings that work best
-	across platforms and with tools such as `git diff` and `git merge`.
-+
-Additionally, if you have a choice between storage formats that are text based
-or non-text based, we recommend storing files in the text format and, if
-necessary, transforming them into the other format.  For example, a text-based
-SQL dump with one record per line will work much better for diffing and merging
-than an actual database file.  Similarly, text-based formats such as Markdown
-and AsciiDoc will work better than binary formats such as Microsoft Word and
-PDF.
-+
-Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or
-build products in the repository is generally not recommended.  Dependencies and
-build products are best stored on an artifact or package server with only
-references, URLs, and hashes stored in the repository.
-+
-We also recommend setting a linkgit:gitattributes[5] file to explicitly mark
-which files are text and which are binary.  If you want Git to guess, you can
-set the attribute `text=auto`.  For example, the following might be appropriate
-in some projects:
-+
-----
-# By default, guess.
-*	text=auto
-# Mark all C files as text.
-*.c	text
-# Mark all JPEG files as binary.
-*.jpg	binary
-----
-+
-These settings help tools pick the right format for output such as patches and
-result in files being checked out in the appropriate line ending for the
-platform.
-
-GIT
----
-Part of the linkgit:git[1] suite