| 1 | gitfaq(7) |
| 2 | ========= |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | gitfaq - Frequently asked questions about using Git |
| 7 | |
| 8 | SYNOPSIS |
| 9 | -------- |
| 10 | gitfaq |
| 11 | |
| 12 | DESCRIPTION |
| 13 | ----------- |
| 14 | |
| 15 | The examples in this FAQ assume a standard POSIX shell, like `bash` or `dash`, |
| 16 | and a user, A U Thor, who has the account `author` on the hosting provider |
| 17 | `git.example.org`. |
| 18 | |
| 19 | Configuration |
| 20 | ------------- |
| 21 | |
| 22 | [[user-name]] |
| 23 | What should I put in `user.name`?:: |
| 24 | You should put your personal name, generally a form using a given name |
| 25 | and family name. For example, the current maintainer of Git uses "Junio |
| 26 | C Hamano". This will be the name portion that is stored in every commit |
| 27 | you make. |
| 28 | + |
| 29 | This configuration doesn't have any effect on authenticating to remote services; |
| 30 | for that, see `credential.username` in linkgit:git-config[1]. |
| 31 | |
| 32 | [[http-postbuffer]] |
| 33 | What does `http.postBuffer` really do?:: |
| 34 | This option changes the size of the buffer that Git uses when pushing |
| 35 | data to a remote over HTTP or HTTPS. If the data is larger than this |
| 36 | size, libcurl, which handles the HTTP support for Git, will use chunked |
| 37 | transfer encoding since it isn't known ahead of time what the size of |
| 38 | the pushed data will be. |
| 39 | + |
| 40 | Leaving this value at the default size is fine unless you know that either the |
| 41 | remote server or a proxy in the middle doesn't support HTTP/1.1 (which |
| 42 | introduced the chunked transfer encoding) or is known to be broken with chunked |
| 43 | data. This is often (erroneously) suggested as a solution for generic push |
| 44 | problems, but since almost every server and proxy supports at least HTTP/1.1, |
| 45 | raising this value usually doesn't solve most push problems. A server or proxy |
| 46 | that didn't correctly support HTTP/1.1 and chunked transfer encoding wouldn't be |
| 47 | that useful on the Internet today, since it would break lots of traffic. |
| 48 | + |
| 49 | Note that increasing this value will increase the memory used on every relevant |
| 50 | push that Git does over HTTP or HTTPS, since the entire buffer is allocated |
| 51 | regardless of whether or not it is all used. Thus, it's best to leave it at the |
| 52 | default unless you are sure you need a different value. |
| 53 | |
| 54 | [[configure-editor]] |
| 55 | How do I configure a different editor?:: |
| 56 | If you haven't specified an editor specifically for Git, it will by default |
| 57 | use the editor you've configured using the `VISUAL` or `EDITOR` environment |
| 58 | variables, or if neither is specified, the system default (which is usually |
| 59 | `vi`). Since some people find `vi` difficult to use or prefer a different |
| 60 | editor, it may be desirable to change the editor used. |
| 61 | + |
| 62 | If you want to configure a general editor for most programs which need one, you |
| 63 | can edit your shell configuration (e.g., `~/.bashrc` or `~/.zshenv`) to contain |
| 64 | a line setting the `EDITOR` or `VISUAL` environment variable to an appropriate |
| 65 | value. For example, if you prefer the editor `nano`, then you could write the |
| 66 | following: |
| 67 | + |
| 68 | ---- |
| 69 | export VISUAL=nano |
| 70 | ---- |
| 71 | + |
| 72 | If you want to configure an editor specifically for Git, you can either set the |
| 73 | `core.editor` configuration value or the `GIT_EDITOR` environment variable. You |
| 74 | can see linkgit:git-var[1] for details on the order in which these options are |
| 75 | consulted. |
| 76 | + |
| 77 | Note that in all cases, the editor value will be passed to the shell, so any |
| 78 | arguments containing spaces should be appropriately quoted. Additionally, if |
| 79 | your editor normally detaches from the terminal when invoked, you should specify |
| 80 | it with an argument that makes it not do that, or else Git will not see any |
| 81 | changes. An example of a configuration addressing both of these issues on |
| 82 | Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`, |
| 83 | which quotes the filename with spaces and specifies the `--nofork` option to |
| 84 | avoid backgrounding the process. |
| 85 | |
| 86 | [[sign-off]] |
| 87 | Why not have `commit.signoff` and other configuration variables?:: |
| 88 | Git intentionally does not (and will not) provide a |
| 89 | configuration variable, such as `commit.signoff`, to |
| 90 | automatically add `--signoff` by default. The reason is to |
| 91 | protect the legal and intentional significance of a sign-off. |
| 92 | If there were more automated and widely publicized ways for |
| 93 | sign-offs to be appended, it would become easier for someone |
| 94 | to argue later that a "Signed-off-by" trailer was just added |
| 95 | out of habit or by automation, without the committer's full |
| 96 | awareness or intent to certify their agreement with the |
| 97 | Developer Certificate of Origin (DCO) or a similar statement. |
| 98 | This could undermine the sign-off’s credibility in legal or |
| 99 | contractual situations. |
| 100 | + |
| 101 | There exists `format.signoff`, but that is a historical mistake, and |
| 102 | it is not an excuse to add more mistakes of the same kind on top. |
| 103 | |
| 104 | |
| 105 | Credentials |
| 106 | ----------- |
| 107 | |
| 108 | [[http-credentials]] |
| 109 | How do I specify my credentials when pushing over HTTP?:: |
| 110 | The easiest way to do this is to use a credential helper via the |
| 111 | `credential.helper` configuration. Most systems provide a standard |
| 112 | choice to integrate with the system credential manager. For example, |
| 113 | Git for Windows provides the `wincred` credential manager, macOS has the |
| 114 | `osxkeychain` credential manager, and Unix systems with a standard |
| 115 | desktop environment can use the `libsecret` credential manager. All of |
| 116 | these store credentials in an encrypted store to keep your passwords or |
| 117 | tokens secure. |
| 118 | + |
| 119 | In addition, you can use the `store` credential manager which stores in a file |
| 120 | in your home directory, or the `cache` credential manager, which does not |
| 121 | permanently store your credentials, but does prevent you from being prompted for |
| 122 | them for a certain period of time. |
| 123 | + |
| 124 | You can also just enter your password when prompted. While it is possible to |
| 125 | place the password (which must be percent-encoded) in the URL, this is not |
| 126 | particularly secure and can lead to accidental exposure of credentials, so it is |
| 127 | not recommended. |
| 128 | |
| 129 | [[http-credentials-environment]] |
| 130 | How do I read a password or token from an environment variable?:: |
| 131 | The `credential.helper` configuration option can also take an arbitrary |
| 132 | shell command that produces the credential protocol on standard output. |
| 133 | This is useful when passing credentials into a container, for example. |
| 134 | + |
| 135 | Such a shell command can be specified by starting the option value with an |
| 136 | exclamation point. If your password or token were stored in the `GIT_TOKEN`, |
| 137 | you could run the following command to set your credential helper: |
| 138 | + |
| 139 | ---- |
| 140 | $ git config credential.helper \ |
| 141 | '!f() { echo username=author; echo "password=$GIT_TOKEN"; };f' |
| 142 | ---- |
| 143 | |
| 144 | [[http-reset-credentials]] |
| 145 | How do I change the password or token I've saved in my credential manager?:: |
| 146 | Usually, if the password or token is invalid, Git will erase it and |
| 147 | prompt for a new one. However, there are times when this doesn't always |
| 148 | happen. To change the password or token, you can erase the existing |
| 149 | credentials and then Git will prompt for new ones. To erase |
| 150 | credentials, use a syntax like the following (substituting your username |
| 151 | and the hostname): |
| 152 | + |
| 153 | ---- |
| 154 | $ echo url=https://author@git.example.org | git credential reject |
| 155 | ---- |
| 156 | |
| 157 | [[multiple-accounts-http]] |
| 158 | How do I use multiple accounts with the same hosting provider using HTTP?:: |
| 159 | Usually the easiest way to distinguish between these accounts is to use |
| 160 | the username in the URL. For example, if you have the accounts `author` |
| 161 | and `committer` on `git.example.org`, you can use the URLs |
| 162 | https://author@git.example.org/org1/project1.git and |
| 163 | https://committer@git.example.org/org2/project2.git. This way, when you |
| 164 | use a credential helper, it will automatically try to look up the |
| 165 | correct credentials for your account. If you already have a remote set |
| 166 | up, you can change the URL with something like `git remote set-url |
| 167 | origin https://author@git.example.org/org1/project1.git` (see |
| 168 | linkgit:git-remote[1] for details). |
| 169 | |
| 170 | [[multiple-accounts-ssh]] |
| 171 | How do I use multiple accounts with the same hosting provider using SSH?:: |
| 172 | With most hosting providers that support SSH, a single key pair uniquely |
| 173 | identifies a user. Therefore, to use multiple accounts, it's necessary |
| 174 | to create a key pair for each account. If you're using a reasonably |
| 175 | modern OpenSSH version, you can create a new key pair with something |
| 176 | like `ssh-keygen -t ed25519 -f ~/.ssh/id_committer`. You can then |
| 177 | register the public key (in this case, `~/.ssh/id_committer.pub`; note |
| 178 | the `.pub`) with the hosting provider. |
| 179 | + |
| 180 | Most hosting providers use a single SSH account for pushing; that is, all users |
| 181 | push to the `git` account (e.g., `git@git.example.org`). If that's the case for |
| 182 | your provider, you can set up multiple aliases in SSH to make it clear which key |
| 183 | pair to use. For example, you could write something like the following in |
| 184 | `~/.ssh/config`, substituting the proper private key file: |
| 185 | + |
| 186 | ---- |
| 187 | # This is the account for author on git.example.org. |
| 188 | Host example_author |
| 189 | HostName git.example.org |
| 190 | User git |
| 191 | # This is the key pair registered for author with git.example.org. |
| 192 | IdentityFile ~/.ssh/id_author |
| 193 | IdentitiesOnly yes |
| 194 | # This is the account for committer on git.example.org. |
| 195 | Host example_committer |
| 196 | HostName git.example.org |
| 197 | User git |
| 198 | # This is the key pair registered for committer with git.example.org. |
| 199 | IdentityFile ~/.ssh/id_committer |
| 200 | IdentitiesOnly yes |
| 201 | ---- |
| 202 | + |
| 203 | Then, you can adjust your push URL to use `git@example_author` or |
| 204 | `git@example_committer` instead of `git@example.org` (e.g., `git remote set-url |
| 205 | git@example_author:org1/project1.git`). |
| 206 | |
| 207 | Transfers |
| 208 | --------- |
| 209 | |
| 210 | [[sync-working-tree]] |
| 211 | How do I sync a working tree across systems?:: |
| 212 | First, decide whether you want to do this at all. Git works best when you |
| 213 | push or pull your work using the typical `git push` and `git fetch` commands |
| 214 | and isn't designed to share a working tree across systems. This is |
| 215 | potentially risky and in some cases can cause repository corruption or data |
| 216 | loss. |
| 217 | + |
| 218 | Usually, doing so will cause `git status` to need to re-read every file in the |
| 219 | working tree. Additionally, Git's security model does not permit sharing a |
| 220 | working tree across untrusted users, so it is only safe to sync a working tree |
| 221 | if it will only be used by a single user across all machines. |
| 222 | + |
| 223 | It is important not to use a cloud syncing service to sync any portion of a Git |
| 224 | repository, since this can cause corruption, such as missing objects, changed |
| 225 | or added files, broken refs, and a wide variety of other problems. These |
| 226 | services tend to sync file by file on a continuous basis and don't understand |
| 227 | the structure of a Git repository. This is especially bad if they sync the |
| 228 | repository in the middle of it being updated, since that is very likely to |
| 229 | cause incomplete or partial updates and therefore data loss. |
| 230 | + |
| 231 | An example of the kind of corruption that can occur is conflicts over the state |
| 232 | of refs, such that both sides end up with different commits on a branch that |
| 233 | the other doesn't have. This can result in important objects becoming |
| 234 | unreferenced and possibly pruned by `git gc`, causing data loss. |
| 235 | + |
| 236 | Therefore, it's better to push your work to either the other system or a |
| 237 | central server using the normal push and pull mechanism. In Git 2.51, Git |
| 238 | learned to import and export stashes, so it's possible to synchronize the state |
| 239 | of the working tree by stashing it with `git stash`, then exporting either all |
| 240 | stashes with `git stash export --to-ref refs/heads/stashes` (assuming you want |
| 241 | to export to the `stashes` branch) or selecting stashes by adding their numbers |
| 242 | to the end of that command. It's also possible to include untracked files by |
| 243 | using the `--include-untracked` argument when stashing the data in the first |
| 244 | place, but be careful not to do this if any of these contain sensitive |
| 245 | information. |
| 246 | + |
| 247 | You can then push the `stashes` branch (or whatever branch you've exported to), |
| 248 | fetch them to the local system (such as with `git fetch origin |
| 249 | +stashes:stashes`), and import the stashes on the other system with `git stash |
| 250 | import stashes` (again, changing the name as necessary). Applying the changes |
| 251 | to the working tree can be done with `git stash pop` or `git stash apply`. |
| 252 | This is the approach that is most robust and most likely to avoid unintended |
| 253 | problems. |
| 254 | + |
| 255 | Having said that, there are some cases where people nevertheless prefer to |
| 256 | share a working tree across systems. If you do this, the recommended approach |
| 257 | is to use `rsync -a --delete-after` (ideally with an encrypted connection such |
| 258 | as with `ssh`) on the root of repository. You should ensure several things |
| 259 | when you do this: |
| 260 | + |
| 261 | * If you have additional worktrees or a separate Git directory, they must be |
| 262 | synced at the same time as the main working tree and repository. |
| 263 | * You are comfortable with the destination directory being an exact copy of the |
| 264 | source directory, _deleting any data that is already there_. |
| 265 | * The repository (including all worktrees and the Git directory) is in a |
| 266 | quiescent state for the duration of the transfer (that is, no operations of |
| 267 | any sort are taking place on it, including background operations like `git |
| 268 | gc` and operations invoked by your editor). |
| 269 | + |
| 270 | Be aware that even with these recommendations, syncing working trees in this |
| 271 | way has some risk since it bypasses Git's normal integrity checking for |
| 272 | repositories, so having backups is advised. You may also wish to do a `git |
| 273 | fsck` to verify the integrity of your data on the destination system after |
| 274 | syncing. |
| 275 | |
| 276 | Common Issues |
| 277 | ------------- |
| 278 | |
| 279 | [[last-commit-amend]] |
| 280 | I've made a mistake in the last commit. How do I change it?:: |
| 281 | You can make the appropriate change to your working tree, run `git add |
| 282 | <file>` or `git rm <file>`, as appropriate, to stage it, and then `git |
| 283 | commit --amend`. Your change will be included in the commit, and you'll |
| 284 | be prompted to edit the commit message again; if you wish to use the |
| 285 | original message verbatim, you can use the `--no-edit` option to `git |
| 286 | commit` in addition, or just save and quit when your editor opens. |
| 287 | |
| 288 | [[undo-previous-change]] |
| 289 | I've made a change with a bug and it's been included in the main branch. How should I undo it?:: |
| 290 | The usual way to deal with this is to use `git revert`. This preserves |
| 291 | the history that the original change was made and was a valuable |
| 292 | contribution, but also introduces a new commit that undoes those changes |
| 293 | because the original had a problem. The commit message of the revert |
| 294 | indicates the commit which was reverted and is usually edited to include |
| 295 | an explanation as to why the revert was made. |
| 296 | |
| 297 | [[ignore-tracked-files]] |
| 298 | How do I ignore changes to a tracked file?:: |
| 299 | Git doesn't provide a way to do this. The reason is that if Git needs |
| 300 | to overwrite this file, such as during a checkout, it doesn't know |
| 301 | whether the changes to the file are precious and should be kept, or |
| 302 | whether they are irrelevant and can safely be destroyed. Therefore, it |
| 303 | has to take the safe route and always preserve them. |
| 304 | + |
| 305 | It's tempting to try to use certain features of `git update-index`, namely the |
| 306 | assume-unchanged and skip-worktree bits, but these don't work properly for this |
| 307 | purpose and shouldn't be used this way. |
| 308 | + |
| 309 | If your goal is to modify a configuration file, it can often be helpful to have |
| 310 | a file checked into the repository which is a template or set of defaults which |
| 311 | can then be copied alongside and modified as appropriate. This second, modified |
| 312 | file is usually ignored to prevent accidentally committing it. |
| 313 | |
| 314 | [[files-in-gitignore-are-tracked]] |
| 315 | I asked Git to ignore various files, yet they are still tracked:: |
| 316 | A `gitignore` file ensures that certain file(s) which are not |
| 317 | tracked by Git remain untracked. However, sometimes particular |
| 318 | file(s) may have been tracked before adding them into the |
| 319 | `.gitignore`, hence they still remain tracked. To untrack and |
| 320 | ignore files/patterns, use `git rm --cached <file/pattern>` |
| 321 | and add a pattern to `.gitignore` that matches the <file>. |
| 322 | See linkgit:gitignore[5] for details. |
| 323 | |
| 324 | [[fetching-and-pulling]] |
| 325 | How do I know if I want to do a fetch or a pull?:: |
| 326 | A fetch stores a copy of the latest changes from the remote |
| 327 | repository, without modifying the working tree or current branch. |
| 328 | You can then at your leisure inspect, merge, rebase on top of, or |
| 329 | ignore the upstream changes. A pull consists of a fetch followed |
| 330 | immediately by either a merge or rebase. See linkgit:git-pull[1]. |
| 331 | |
| 332 | [[proxy]] |
| 333 | Can I use a proxy with Git?:: |
| 334 | Yes, Git supports the use of proxies. Git honors the standard `http_proxy`, |
| 335 | `https_proxy`, and `no_proxy` environment variables commonly used on Unix, and |
| 336 | it also can be configured with `http.proxy` and similar options for HTTPS (see |
| 337 | linkgit:git-config[1]). The `http.proxy` and related options can be |
| 338 | customized on a per-URL pattern basis. In addition, Git can in theory |
| 339 | function normally with transparent proxies that exist on the network. |
| 340 | + |
| 341 | For SSH, Git can support a proxy using OpenSSH's `ProxyCommand`. Commonly used |
| 342 | tools include `netcat` and `socat`. However, they must be configured not to |
| 343 | exit when seeing EOF on standard input, which usually means that `netcat` will |
| 344 | require `-q` and `socat` will require a timeout with something like `-t 10`. |
| 345 | This is required because the way the Git SSH server knows that no more requests |
| 346 | will be made is an EOF on standard input, but when that happens, the server may |
| 347 | not have yet processed the final request, so dropping the connection at that |
| 348 | point would interrupt that request. |
| 349 | + |
| 350 | An example configuration entry in `~/.ssh/config` with an HTTP proxy might look |
| 351 | like this: |
| 352 | + |
| 353 | ---- |
| 354 | Host git.example.org |
| 355 | User git |
| 356 | ProxyCommand socat -t 10 - PROXY:proxy.example.org:%h:%p,proxyport=8080 |
| 357 | ---- |
| 358 | + |
| 359 | Note that in all cases, for Git to work properly, the proxy must be completely |
| 360 | transparent. The proxy cannot modify, tamper with, or buffer the connection in |
| 361 | any way, or Git will almost certainly fail to work. Note that many proxies, |
| 362 | including many TLS middleboxes, Windows antivirus and firewall programs other |
| 363 | than Windows Defender and Windows Firewall, and filtering proxies fail to meet |
| 364 | this standard, and as a result end up breaking Git. Because of the many |
| 365 | reports of problems and their poor security history, we recommend against the |
| 366 | use of these classes of software and devices. |
| 367 | |
| 368 | Merging and Rebasing |
| 369 | -------------------- |
| 370 | |
| 371 | [[long-running-squash-merge]] |
| 372 | What kinds of problems can occur when merging long-lived branches with squash merges?:: |
| 373 | In general, there are a variety of problems that can occur when using squash |
| 374 | merges to merge two branches multiple times. These can include seeing extra |
| 375 | commits in `git log` output, with a GUI, or when using the `...` notation to |
| 376 | express a range, as well as the possibility of needing to re-resolve conflicts |
| 377 | again and again. |
| 378 | + |
| 379 | When Git does a normal merge between two branches, it considers exactly three |
| 380 | points: the two branches and a third commit, called the _merge base_, which is |
| 381 | usually the common ancestor of the commits. The result of the merge is the sum |
| 382 | of the changes between the merge base and each head. When you merge two |
| 383 | branches with a regular merge commit, this results in a new commit which will |
| 384 | end up as a merge base when they're merged again, because there is now a new |
| 385 | common ancestor. Git doesn't have to consider changes that occurred before the |
| 386 | merge base, so you don't have to re-resolve any conflicts you resolved before. |
| 387 | + |
| 388 | When you perform a squash merge, a merge commit isn't created; instead, the |
| 389 | changes from one side are applied as a regular commit to the other side. This |
| 390 | means that the merge base for these branches won't have changed, and so when Git |
| 391 | goes to perform its next merge, it considers all of the changes that it |
| 392 | considered the last time plus the new changes. That means any conflicts may |
| 393 | need to be re-resolved. Similarly, anything using the `...` notation in `git |
| 394 | diff`, `git log`, or a GUI will result in showing all of the changes since the |
| 395 | original merge base. |
| 396 | + |
| 397 | As a consequence, if you want to merge two long-lived branches repeatedly, it's |
| 398 | best to always use a regular merge commit. |
| 399 | |
| 400 | [[merge-two-revert-one]] |
| 401 | If I make a change on two branches but revert it on one, why does the merge of those branches include the change?:: |
| 402 | By default, when Git does a merge, it uses a strategy called the `ort` |
| 403 | strategy, which does a fancy three-way merge. In such a case, when Git |
| 404 | performs the merge, it considers exactly three points: the two heads and a |
| 405 | third point, called the _merge base_, which is usually the common ancestor of |
| 406 | those commits. Git does not consider the history or the individual commits |
| 407 | that have happened on those branches at all. |
| 408 | + |
| 409 | As a result, if both sides have a change and one side has reverted that change, |
| 410 | the result is to include the change. This is because the code has changed on |
| 411 | one side and there is no net change on the other, and in this scenario, Git |
| 412 | adopts the change. |
| 413 | + |
| 414 | If this is a problem for you, you can do a rebase instead, rebasing the branch |
| 415 | with the revert onto the other branch. A rebase in this scenario will revert |
| 416 | the change, because a rebase applies each individual commit, including the |
| 417 | revert. Note that rebases rewrite history, so you should avoid rebasing |
| 418 | published branches unless you're sure you're comfortable with that. See the |
| 419 | NOTES section in linkgit:git-rebase[1] for more details. |
| 420 | |
| 421 | Hooks |
| 422 | ----- |
| 423 | |
| 424 | [[restrict-with-hooks]] |
| 425 | How do I use hooks to prevent users from making certain changes?:: |
| 426 | The only safe place to make these changes is on the remote repository |
| 427 | (i.e., the Git server), usually in the `pre-receive` hook or in a |
| 428 | continuous integration (CI) system. These are the locations in which |
| 429 | policy can be enforced effectively. |
| 430 | + |
| 431 | It's common to try to use `pre-commit` hooks (or, for commit messages, |
| 432 | `commit-msg` hooks) to check these things, which is great if you're working as a |
| 433 | solo developer and want the tooling to help you. However, using hooks on a |
| 434 | developer machine is not effective as a policy control because a user can bypass |
| 435 | these hooks with `--no-verify` without being noticed (among various other ways). |
| 436 | Git assumes that the user is in control of their local repositories and doesn't |
| 437 | try to prevent this or tattle on the user. |
| 438 | + |
| 439 | In addition, some advanced users find `pre-commit` hooks to be an impediment to |
| 440 | workflows that use temporary commits to stage work in progress or that create |
| 441 | fixup commits, so it's better to push these kinds of checks to the server |
| 442 | anyway. |
| 443 | |
| 444 | Cross-Platform Issues |
| 445 | --------------------- |
| 446 | |
| 447 | [[windows-text-binary]] |
| 448 | I'm on Windows and my text files are detected as binary.:: |
| 449 | Git works best when you store text files as UTF-8. Many programs on |
| 450 | Windows support UTF-8, but some do not and only use the little-endian |
| 451 | UTF-16 format, which Git detects as binary. If you can't use UTF-8 with |
| 452 | your programs, you can specify a working tree encoding that indicates |
| 453 | which encoding your files should be checked out with, while still |
| 454 | storing these files as UTF-8 in the repository. This allows tools like |
| 455 | linkgit:git-diff[1] to work as expected, while still allowing your tools |
| 456 | to work. |
| 457 | + |
| 458 | To do so, you can specify a linkgit:gitattributes[5] pattern with the |
| 459 | `working-tree-encoding` attribute. For example, the following pattern sets all |
| 460 | C files to use UTF-16LE-BOM, which is a common encoding on Windows: |
| 461 | + |
| 462 | ---- |
| 463 | *.c working-tree-encoding=UTF-16LE-BOM |
| 464 | ---- |
| 465 | + |
| 466 | You will need to run `git add --renormalize` to have this take effect. Note |
| 467 | that if you are making these changes on a project that is used across platforms, |
| 468 | you'll probably want to make it in a per-user configuration file or in the one |
| 469 | in `$GIT_DIR/info/attributes`, since making it in a `.gitattributes` file in the |
| 470 | repository will apply to all users of the repository. |
| 471 | + |
| 472 | See the following entry for information about normalizing line endings as well, |
| 473 | and see linkgit:gitattributes[5] for more information about attribute files. |
| 474 | |
| 475 | [[windows-diff-control-m]] |
| 476 | I'm on Windows and git diff shows my files as having a `^M` at the end.:: |
| 477 | By default, Git expects files to be stored with Unix line endings. As such, |
| 478 | the carriage return (`^M`) that is part of a Windows line ending is shown |
| 479 | because it is considered to be trailing whitespace. Git defaults to showing |
| 480 | trailing whitespace only on new lines, not existing ones. |
| 481 | + |
| 482 | You can store the files in the repository with Unix line endings and convert |
| 483 | them automatically to your platform's line endings. To do that, set the |
| 484 | configuration option `core.eol` to `native` and see |
| 485 | <<recommended-storage-settings,the question on recommended storage settings>> |
| 486 | for information about how to configure files as text or binary. |
| 487 | + |
| 488 | You can also control this behavior with the `core.whitespace` setting if you |
| 489 | don't wish to remove the carriage returns from your line endings. |
| 490 | |
| 491 | [[always-modified-files-case]] |
| 492 | Why do I have a file that's always modified?:: |
| 493 | Internally, Git always stores file names as sequences of bytes and doesn't |
| 494 | perform any encoding or case folding. However, Windows and macOS by default |
| 495 | both perform case folding on file names. As a result, it's possible to end up |
| 496 | with multiple files or directories whose names differ only in case. Git can |
| 497 | handle this just fine, but the file system can store only one of these files, |
| 498 | so when Git reads the other file to see its contents, it looks modified. |
| 499 | + |
| 500 | It's best to remove one of the files such that you only have one file. You can |
| 501 | do this with commands like the following (assuming two files `AFile.txt` and |
| 502 | `afile.txt`) on an otherwise clean working tree: |
| 503 | + |
| 504 | ---- |
| 505 | $ git rm --cached AFile.txt |
| 506 | $ git commit -m 'Remove files conflicting in case' |
| 507 | $ git checkout . |
| 508 | ---- |
| 509 | + |
| 510 | This avoids touching the disk, but removes the additional file. Your project |
| 511 | may prefer to adopt a naming convention, such as all-lowercase names, to avoid |
| 512 | this problem from occurring again; such a convention can be checked using a |
| 513 | `pre-receive` hook or as part of a continuous integration (CI) system. |
| 514 | + |
| 515 | It is also possible for perpetually modified files to occur on any platform if a |
| 516 | smudge or clean filter is in use on your system but a file was previously |
| 517 | committed without running the smudge or clean filter. To fix this, run the |
| 518 | following on an otherwise clean working tree: |
| 519 | + |
| 520 | ---- |
| 521 | $ git add --renormalize . |
| 522 | ---- |
| 523 | |
| 524 | [[recommended-storage-settings]] |
| 525 | What's the recommended way to store files in Git?:: |
| 526 | While Git can store and handle any file of any type, there are some |
| 527 | settings that work better than others. In general, we recommend that |
| 528 | text files be stored in UTF-8 without a byte-order mark (BOM) with LF |
| 529 | (Unix-style) endings. We also recommend the use of UTF-8 (again, |
| 530 | without BOM) in commit messages. These are the settings that work best |
| 531 | across platforms and with tools such as `git diff` and `git merge`. |
| 532 | + |
| 533 | Additionally, if you have a choice between storage formats that are text based |
| 534 | or non-text based, we recommend storing files in the text format and, if |
| 535 | necessary, transforming them into the other format. For example, a text-based |
| 536 | SQL dump with one record per line will work much better for diffing and merging |
| 537 | than an actual database file. Similarly, text-based formats such as Markdown |
| 538 | and AsciiDoc will work better than binary formats such as Microsoft Word and |
| 539 | PDF. |
| 540 | + |
| 541 | Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or |
| 542 | build products in the repository is generally not recommended. Dependencies and |
| 543 | build products are best stored on an artifact or package server with only |
| 544 | references, URLs, and hashes stored in the repository. |
| 545 | + |
| 546 | We also recommend setting a linkgit:gitattributes[5] file to explicitly mark |
| 547 | which files are text and which are binary. If you want Git to guess, you can |
| 548 | set the attribute `text=auto`. |
| 549 | + |
| 550 | With text files, Git will generally ensure that LF endings are used in the |
| 551 | repository. The `core.autocrlf` and `core.eol` configuration variables specify |
| 552 | what line-ending convention is followed when any text file is checked out. You |
| 553 | can also use the `eol` attribute (e.g., `eol=crlf`) to override which files get |
| 554 | what line-ending treatment. |
| 555 | + |
| 556 | For example, generally shell files must have LF endings and batch files must |
| 557 | have CRLF endings, so the following might be appropriate in some projects: |
| 558 | + |
| 559 | ---- |
| 560 | # By default, guess. |
| 561 | * text=auto |
| 562 | # Mark all C files as text. |
| 563 | *.c text |
| 564 | # Ensure all shell files have LF endings and all batch files have CRLF |
| 565 | # endings in the working tree and both have LF in the repo. |
| 566 | *.sh text eol=lf |
| 567 | *.bat text eol=crlf |
| 568 | # Mark all JPEG files as binary. |
| 569 | *.jpg binary |
| 570 | ---- |
| 571 | + |
| 572 | These settings help tools pick the right format for output such as patches and |
| 573 | result in files being checked out in the appropriate line ending for the |
| 574 | platform. |
| 575 | |
| 576 | GIT |
| 577 | --- |
| 578 | Part of the linkgit:git[1] suite |