NAME<\/a> gitfaq \u2212 Frequently asked questions about using Git<\/p>\n gitfaq<\/p>\n The examples in this FAQ assume a standard POSIX shell, like bash<\/b> or dash<\/b>, and a user, A U Thor, who has the account author<\/b> on the hosting provider git.example.org<\/b>.<\/p>\n What should I put in user.name<\/b>?<\/p>\n 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.<\/p>\n This configuration doesn\u2019t have any effect on authenticating to remote services; for that, see credential.username<\/b> in git-config<\/b>(1).<\/p>\n What does http.postBuffer<\/b> really do?<\/p>\n 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\u2019t known ahead of time what the size of the pushed data will be.<\/p>\n Leaving this value at the default size is fine unless you know that either the remote server or a proxy in the middle doesn\u2019t 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\u2019t solve most push problems. A server or proxy that didn\u2019t correctly support HTTP\/1.1 and chunked transfer encoding wouldn\u2019t be that useful on the Internet today, since it would break lots of traffic.<\/p>\n 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\u2019s best to leave it at the default unless you are sure you need a different value.<\/p>\n How do I configure a different editor?<\/p>\n If you haven\u2019t specified an editor specifically for Git, it will by default use the editor you\u2019ve configured using the VISUAL<\/b> or EDITOR<\/b> environment variables, or if neither is specified, the system default (which is usually vi<\/b>). Since some people find vi<\/b> difficult to use or prefer a different editor, it may be desirable to change the editor used.<\/p>\n If you want to configure a general editor for most programs which need one, you can edit your shell configuration (e.g., ~\/.bashrc<\/b> or ~\/.zshenv<\/b>) to contain a line setting the EDITOR<\/b> or VISUAL<\/b> environment variable to an appropriate value. For example, if you prefer the editor nano<\/b>, then you could write the following:<\/p>\n export VISUAL=nano<\/p>\n If you want to configure an editor specifically for Git, you can either set the core.editor<\/b> configuration value or the GIT_EDITOR<\/b> environment variable. You can see git-var<\/b>(1) for details on the order in which these options are consulted.<\/p>\n 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 FilesVimgvim.exe” \u2212\u2212nofork<\/b>, which quotes the filename with spaces and specifies the \u2212\u2212nofork<\/b> option to avoid backgrounding the process.<\/p>\n How do I specify my credentials when pushing over HTTP?<\/p>\n The easiest way to do this is to use a credential helper via the credential.helper<\/b> configuration. Most systems provide a standard choice to integrate with the system credential manager. For example, Git for Windows provides the wincred<\/b> credential manager, macOS has the osxkeychain<\/b> credential manager, and Unix systems with a standard desktop environment can use the libsecret<\/b> credential manager. All of these store credentials in an encrypted store to keep your passwords or tokens secure.<\/p>\n In addition, you can use the store<\/b> credential manager which stores in a file in your home directory, or the cache<\/b> credential manager, which does not permanently store your credentials, but does prevent you from being prompted for them for a certain period of time.<\/p>\n You can also just enter your password when prompted. While it is possible to place the password (which must be percent\u2212encoded) in the URL, this is not particularly secure and can lead to accidental exposure of credentials, so it is not recommended.<\/p>\n How do I read a password or token from an environment variable?<\/p>\n The credential.helper<\/b> 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.<\/p>\n 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<\/b>, you could run the following command to set your credential helper:<\/p>\n $ git config credential.helper How do I change the password or token I\u2019ve saved in my credential manager?<\/p>\n 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\u2019t 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):<\/p>\n $ echo url=https:\/\/author@git.example.org | git credential reject<\/p>\n How do I use multiple accounts with the same hosting provider using HTTP?<\/p>\n 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<\/b> and committer<\/b> on git.example.org<\/b>, you can use the URLs https:\/\/author@git.example.org\/org1\/project1.git<\/font><\/b> and<\/font> https:\/\/committer@git.example.org\/org2\/project2.git<\/font><\/b>. 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\u2212url origin https:\/\/author@git.example.org\/org1\/project1.git<\/b> (see git-remote<\/b>(1) for details).<\/font><\/p>\n How do I use multiple accounts with the same hosting provider using SSH?<\/font><\/p>\n With most hosting providers that support SSH, a single key pair uniquely identifies a user. Therefore, to use multiple accounts, it\u2019s necessary to create a key pair for each account. If you\u2019re using a reasonably modern OpenSSH version, you can create a new key pair with something like ssh\u2212keygen \u2212t ed25519 \u2212f ~\/.ssh\/id_committer<\/b>. You can then register the public key (in this case, ~\/.ssh\/id_committer.pub<\/b>; note the .pub<\/b>) with the hosting provider.<\/font><\/p>\n Most hosting providers use a single SSH account for pushing; that is, all users push to the git<\/b> account (e.g., git@git.example.org<\/b>). If that\u2019s 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<\/b>, substituting the proper private key file:<\/font><\/p>\n # This is the account for author on git.example.org. Then, you can adjust your push URL to use git@example_author<\/b> or git@example_committer<\/b> instead of git@example.org<\/b> (e.g., git remote set\u2212url git@example_author:org1\/project1.git<\/b>).<\/font><\/p>\n I\u2019ve made a mistake in the last commit. How do I change it?<\/font><\/p>\n You can make the appropriate change to your working tree, run git add I\u2019ve made a change with a bug and it\u2019s been included in the main branch. How should I undo it?<\/font><\/p>\n The usual way to deal with this is to use git revert<\/b>. 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.<\/font><\/p>\n How do I ignore changes to a tracked file?<\/font><\/p>\n Git doesn\u2019t provide a way to do this. The reason is that if Git needs to overwrite this file, such as during a checkout, it doesn\u2019t 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.<\/font><\/p>\n It\u2019s tempting to try to use certain features of git update\u2212index<\/b>, namely the assume\u2212unchanged and skip\u2212worktree bits, but these don\u2019t work properly for this purpose and shouldn\u2019t be used this way.<\/font><\/p>\n 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.<\/font><\/p>\n I asked Git to ignore various files, yet they are still tracked<\/font><\/p>\n A gitignore<\/b> 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<\/b>, hence they still remain tracked. To untrack and ignore files\/patterns, use git rm \u2212\u2212cached How do I know if I want to do a fetch or a pull?<\/font><\/p>\n 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 git-pull<\/b>(1).<\/font><\/p>\n What kinds of problems can occur when merging long\u2212lived branches with squash merges?<\/font><\/p>\n 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<\/b> output, with a GUI, or when using the …<\/b> notation to express a range, as well as the possibility of needing to re\u2212resolve conflicts again and again.<\/font><\/p>\n 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<\/i>, 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\u2019re merged again, because there is now a new common ancestor. Git doesn\u2019t have to consider changes that occurred before the merge base, so you don\u2019t have to re\u2212resolve any conflicts you resolved before.<\/font><\/p>\n When you perform a squash merge, a merge commit isn\u2019t 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\u2019t 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\u2212resolved. Similarly, anything using the …<\/b> notation in git diff<\/b>, git log<\/b>, or a GUI will result in showing all of the changes since the original merge base.<\/font><\/p>\n As a consequence, if you want to merge two long\u2212lived branches repeatedly, it\u2019s best to always use a regular merge commit.<\/font><\/p>\n If I make a change on two branches but revert it on one, why does the merge of those branches include the change?<\/font><\/p>\n By default, when Git does a merge, it uses a strategy called the recursive strategy, which does a fancy three\u2212way 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<\/i>, 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.<\/font><\/p>\n 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.<\/font><\/p>\n 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\u2019re sure you\u2019re comfortable with that. See the NOTES section in git-rebase<\/b>(1) for more details.<\/font><\/p>\n How do I use hooks to prevent users from making certain changes?<\/font><\/p>\n The only safe place to make these changes is on the remote repository (i.e., the Git server), usually in the pre\u2212receive<\/b> hook or in a continuous integration (CI) system. These are the locations in which policy can be enforced effectively.<\/font><\/p>\n It\u2019s common to try to use pre\u2212commit<\/b> hooks (or, for commit messages, commit\u2212msg<\/b> hooks) to check these things, which is great if you\u2019re 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 \u2212\u2212no\u2212verify<\/b> without being noticed (among various other ways). Git assumes that the user is in control of their local repositories and doesn\u2019t try to prevent this or tattle on the user.<\/font><\/p>\n In addition, some advanced users find pre\u2212commit<\/b> hooks to be an impediment to workflows that use temporary commits to stage work in progress or that create fixup commits, so it\u2019s better to push these kinds of checks to the server anyway.<\/font><\/p>\n I\u2019m on Windows and my text files are detected as binary.<\/font><\/p>\n Git works best when you store text files as UTF\u22128. Many programs on Windows support UTF\u22128, but some do not and only use the little\u2212endian UTF\u221216 format, which Git detects as binary. If you can\u2019t use UTF\u22128 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\u22128 in the repository. This allows tools like git-diff<\/b>(1) to work as expected, while still allowing your tools to work.<\/font><\/p>\n To do so, you can specify a gitattributes<\/b>(5) pattern with the working\u2212tree\u2212encoding<\/b> attribute. For example, the following pattern sets all C files to use UTF\u221216LE\u2212BOM, which is a common encoding on Windows:<\/font><\/p>\n *.c working\u2212tree\u2212encoding=UTF\u221216LE\u2212BOM<\/font><\/p>\n You will need to run git add \u2212\u2212renormalize<\/b> to have this take effect. Note that if you are making these changes on a project that is used across platforms, you\u2019ll probably want to make it in a per\u2212user configuration file or in the one in $GIT_DIR\/info\/attributes<\/b>, since making it in a .gitattributes<\/b> file in the repository will apply to all users of the repository.<\/font><\/p>\n See the following entry for information about normalizing line endings as well, and see gitattributes<\/b>(5) for more information about attribute files.<\/font><\/p>\n I\u2019m on Windows and git diff shows my files as having a ^M<\/b> at the end.<\/font><\/p>\n By default, Git expects files to be stored with Unix line endings. As such, the carriage return (^M<\/b>) 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.<\/font><\/p>\n You can store the files in the repository with Unix line endings and convert them automatically to your platform\u2019s line endings. To do that, set the configuration option core.eol<\/b> to native<\/b> and see the following entry for information about how to configure files as text or binary.<\/font><\/p>\n You can also control this behavior with the core.whitespace<\/b> setting if you don\u2019t wish to remove the carriage returns from your line endings.<\/font><\/p>\n Why do I have a file that\u2019s always modified?<\/font><\/p>\n Internally, Git always stores file names as sequences of bytes and doesn\u2019t perform any encoding or case folding. However, Windows and macOS by default both perform case folding on file names. As a result, it\u2019s 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.<\/font><\/p>\n It\u2019s 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<\/b> and afile.txt<\/b>) on an otherwise clean working tree:<\/font><\/p>\n $ git rm \u2212\u2212cached AFile.txt This avoids touching the disk, but removes the additional file. Your project may prefer to adopt a naming convention, such as all\u2212lowercase names, to avoid this problem from occurring again; such a convention can be checked using a pre\u2212receive<\/b> hook or as part of a continuous integration (CI) system.<\/font><\/p>\n 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:<\/font><\/p>\n $ git add \u2212\u2212renormalize .<\/font><\/p>\n What\u2019s the recommended way to store files in Git?<\/font><\/p>\n 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\u22128 without a byte\u2212order mark (BOM) with LF (Unix\u2212style) endings. We also recommend the use of UTF\u22128 (again, without BOM) in commit messages. These are the settings that work best across platforms and with tools such as git diff<\/b> and git merge<\/b>.<\/font><\/p>\n Additionally, if you have a choice between storage formats that are text based or non\u2212text based, we recommend storing files in the text format and, if necessary, transforming them into the other format. For example, a text\u2212based SQL dump with one record per line will work much better for diffing and merging than an actual database file. Similarly, text\u2212based formats such as Markdown and AsciiDoc will work better than binary formats such as Microsoft Word and PDF.<\/font><\/p>\n 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.<\/font><\/p>\n We also recommend setting a gitattributes<\/b>(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<\/b>. For example, the following might be appropriate in some projects:<\/font><\/p>\n # By default, guess. 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.<\/font><\/p>\n Part of the git<\/b>(1) suite<\/font><\/p>\n gitfaq \u2212 Frequently asked questions about using Git <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[971],"tags":[973,1082,972],"class_list":["post-3993","post","type-post","status-publish","format-standard","hentry","category-7-miscelanea","tag-973","tag-gitfaq","tag-man7"],"gutentor_comment":0,"_links":{"self":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/3993","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/comments?post=3993"}],"version-history":[{"count":0,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/3993\/revisions"}],"wp:attachment":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/media?parent=3993"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/categories?post=3993"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/tags?post=3993"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
SYNOPSIS<\/a>
DESCRIPTION<\/a>
CONFIGURATION<\/a>
CREDENTIALS<\/a>
COMMON ISSUES<\/a>
MERGING AND REBASING<\/a>
HOOKS<\/a>
CROSS\u2212PLATFORM ISSUES<\/a>
GIT<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
SYNOPSIS <\/a> <\/h2>\n
DESCRIPTION <\/a> <\/h2>\n
CONFIGURATION <\/a> <\/h2>\n
CREDENTIALS <\/a> <\/h2>\n
‘!f() { echo username=author; echo “password=$GIT_TOKEN”; };f’<\/p>\n
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<\/font><\/p>\nCOMMON ISSUES <\/a> <\/h2>\n
MERGING AND REBASING <\/a> <\/h2>\n
HOOKS <\/a> <\/h2>\n
CROSS\u2212PLATFORM ISSUES <\/a> <\/h2>\n
$ git commit \u2212m ‘Remove files conflicting in case’
$ git checkout .<\/font><\/p>\n
bodies manpages.csv script_extrae_body.sh script.sh usr text=auto
# Mark all C files as text.
*.c text
# Mark all JPEG files as binary.
*.jpg binary<\/font><\/p>\nGIT <\/a> <\/h2>\n
\n","protected":false},"excerpt":{"rendered":"