| 1 | gitattributes(5) |
| 2 | ================ |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | gitattributes - Defining attributes per path |
| 7 | |
| 8 | SYNOPSIS |
| 9 | -------- |
| 10 | $GIT_DIR/info/attributes, .gitattributes |
| 11 | |
| 12 | |
| 13 | DESCRIPTION |
| 14 | ----------- |
| 15 | |
| 16 | A `gitattributes` file is a simple text file that gives |
| 17 | `attributes` to pathnames. |
| 18 | |
| 19 | Each line in `gitattributes` file is of form: |
| 20 | |
| 21 | pattern attr1 attr2 ... |
| 22 | |
| 23 | That is, a pattern followed by an attributes list, |
| 24 | separated by whitespaces. Leading and trailing whitespaces are |
| 25 | ignored. Lines that begin with '#' are ignored. Patterns |
| 26 | that begin with a double quote are quoted in C style. |
| 27 | When the pattern matches the path in question, the attributes |
| 28 | listed on the line are given to the path. |
| 29 | |
| 30 | Each attribute can be in one of these states for a given path: |
| 31 | |
| 32 | Set:: |
| 33 | |
| 34 | The path has the attribute with special value "true"; |
| 35 | this is specified by listing only the name of the |
| 36 | attribute in the attribute list. |
| 37 | |
| 38 | Unset:: |
| 39 | |
| 40 | The path has the attribute with special value "false"; |
| 41 | this is specified by listing the name of the attribute |
| 42 | prefixed with a dash `-` in the attribute list. |
| 43 | |
| 44 | Set to a value:: |
| 45 | |
| 46 | The path has the attribute with specified string value; |
| 47 | this is specified by listing the name of the attribute |
| 48 | followed by an equal sign `=` and its value in the |
| 49 | attribute list. |
| 50 | |
| 51 | Unspecified:: |
| 52 | |
| 53 | No pattern matches the path, and nothing says if |
| 54 | the path has or does not have the attribute, the |
| 55 | attribute for the path is said to be Unspecified. |
| 56 | |
| 57 | When more than one pattern matches the path, a later line |
| 58 | overrides an earlier line. This overriding is done per |
| 59 | attribute. |
| 60 | |
| 61 | The rules by which the pattern matches paths are the same as in |
| 62 | `.gitignore` files (see linkgit:gitignore[5]), with a few exceptions: |
| 63 | |
| 64 | - negative patterns are forbidden |
| 65 | |
| 66 | - patterns that match a directory do not recursively match paths |
| 67 | inside that directory (so using the trailing-slash `path/` syntax is |
| 68 | pointless in an attributes file; use `path/**` instead) |
| 69 | |
| 70 | When deciding what attributes are assigned to a path, Git |
| 71 | consults `$GIT_DIR/info/attributes` file (which has the highest |
| 72 | precedence), `.gitattributes` file in the same directory as the |
| 73 | path in question, and its parent directories up to the toplevel of the |
| 74 | work tree (the further the directory that contains `.gitattributes` |
| 75 | is from the path in question, the lower its precedence). Finally |
| 76 | global and system-wide files are considered (they have the lowest |
| 77 | precedence). |
| 78 | |
| 79 | When the `.gitattributes` file is missing from the work tree, the |
| 80 | path in the index is used as a fall-back. During checkout process, |
| 81 | `.gitattributes` in the index is used and then the file in the |
| 82 | working tree is used as a fall-back. |
| 83 | |
| 84 | If you wish to affect only a single repository (i.e., to assign |
| 85 | attributes to files that are particular to |
| 86 | one user's workflow for that repository), then |
| 87 | attributes should be placed in the `$GIT_DIR/info/attributes` file. |
| 88 | Attributes which should be version-controlled and distributed to other |
| 89 | repositories (i.e., attributes of interest to all users) should go into |
| 90 | `.gitattributes` files. Attributes that should affect all repositories |
| 91 | for a single user should be placed in a file specified by the |
| 92 | `core.attributesFile` configuration option (see linkgit:git-config[1]). |
| 93 | Its default value is $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME |
| 94 | is either not set or empty, $HOME/.config/git/attributes is used instead. |
| 95 | Attributes for all users on a system should be placed in the |
| 96 | `$(prefix)/etc/gitattributes` file. |
| 97 | |
| 98 | Sometimes you would need to override a setting of an attribute |
| 99 | for a path to `Unspecified` state. This can be done by listing |
| 100 | the name of the attribute prefixed with an exclamation point `!`. |
| 101 | |
| 102 | |
| 103 | RESERVED BUILTIN_* ATTRIBUTES |
| 104 | ----------------------------- |
| 105 | |
| 106 | builtin_* is a reserved namespace for builtin attribute values. Any |
| 107 | user defined attributes under this namespace will be ignored and |
| 108 | trigger a warning. |
| 109 | |
| 110 | `builtin_objectmode` |
| 111 | ~~~~~~~~~~~~~~~~~~~~ |
| 112 | This attribute is for filtering files by their file bit modes (40000, |
| 113 | 120000, 160000, 100755, 100644). e.g. ':(attr:builtin_objectmode=160000)'. |
| 114 | You may also check these values with `git check-attr builtin_objectmode -- <file>`. |
| 115 | If the object is not in the index `git check-attr --cached` will return unspecified. |
| 116 | |
| 117 | |
| 118 | EFFECTS |
| 119 | ------- |
| 120 | |
| 121 | Certain operations by Git can be influenced by assigning |
| 122 | particular attributes to a path. Currently, the following |
| 123 | operations are attributes-aware. |
| 124 | |
| 125 | Checking-out and checking-in |
| 126 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 127 | |
| 128 | These attributes affect how the contents stored in the |
| 129 | repository are copied to the working tree files when commands |
| 130 | such as 'git switch', 'git checkout' and 'git merge' run. |
| 131 | They also affect how |
| 132 | Git stores the contents you prepare in the working tree in the |
| 133 | repository upon 'git add' and 'git commit'. |
| 134 | |
| 135 | `text` |
| 136 | ^^^^^^ |
| 137 | |
| 138 | This attribute marks the path as a text file, which enables end-of-line |
| 139 | conversion: When a matching file is added to the index, the file's line |
| 140 | endings are normalized to LF in the index. Conversely, when the file is |
| 141 | copied from the index to the working directory, its line endings may be |
| 142 | converted from LF to CRLF depending on the `eol` attribute, the Git |
| 143 | config, and the platform (see explanation of `eol` below). |
| 144 | |
| 145 | Set:: |
| 146 | |
| 147 | Setting the `text` attribute on a path enables end-of-line |
| 148 | conversion on checkin and checkout as described above. Line endings |
| 149 | are normalized to LF in the index every time the file is checked in, |
| 150 | even if the file was previously added to Git with CRLF line endings. |
| 151 | |
| 152 | Unset:: |
| 153 | |
| 154 | Unsetting the `text` attribute on a path tells Git not to |
| 155 | attempt any end-of-line conversion upon checkin or checkout. |
| 156 | |
| 157 | Set to string value "auto":: |
| 158 | |
| 159 | When `text` is set to "auto", Git decides by itself whether the file |
| 160 | is text or binary. If it is text and the file was not already in |
| 161 | Git with CRLF endings, line endings are converted on checkin and |
| 162 | checkout as described above. Otherwise, no conversion is done on |
| 163 | checkin or checkout. |
| 164 | |
| 165 | Unspecified:: |
| 166 | |
| 167 | If the `text` attribute is unspecified, Git uses the |
| 168 | `core.autocrlf` configuration variable to determine if the |
| 169 | file should be converted. |
| 170 | |
| 171 | Any other value causes Git to act as if `text` has been left |
| 172 | unspecified. |
| 173 | |
| 174 | `eol` |
| 175 | ^^^^^ |
| 176 | |
| 177 | This attribute marks a path to use a specific line-ending style in the |
| 178 | working tree when it is checked out. It has effect only if `text` or |
| 179 | `text=auto` is set (see above), but specifying `eol` automatically sets |
| 180 | `text` if `text` was left unspecified. |
| 181 | |
| 182 | Set to string value "crlf":: |
| 183 | |
| 184 | This setting converts the file's line endings in the working |
| 185 | directory to CRLF when the file is checked out. |
| 186 | |
| 187 | Set to string value "lf":: |
| 188 | |
| 189 | This setting uses the same line endings in the working directory as |
| 190 | in the index when the file is checked out. |
| 191 | |
| 192 | Unspecified:: |
| 193 | |
| 194 | If the `eol` attribute is unspecified for a file, its line endings |
| 195 | in the working directory are determined by the `core.autocrlf` or |
| 196 | `core.eol` configuration variable (see the definitions of those |
| 197 | options in linkgit:git-config[1]). If `text` is set but neither of |
| 198 | those variables is, the default is `eol=crlf` on Windows and |
| 199 | `eol=lf` on all other platforms. |
| 200 | |
| 201 | Backwards compatibility with `crlf` attribute |
| 202 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 203 | |
| 204 | For backwards compatibility, the `crlf` attribute is interpreted as |
| 205 | follows: |
| 206 | |
| 207 | ------------------------ |
| 208 | crlf text |
| 209 | -crlf -text |
| 210 | crlf=input eol=lf |
| 211 | ------------------------ |
| 212 | |
| 213 | End-of-line conversion |
| 214 | ^^^^^^^^^^^^^^^^^^^^^^ |
| 215 | |
| 216 | While Git normally leaves file contents alone, it can be configured to |
| 217 | normalize line endings to LF in the repository and, optionally, to |
| 218 | convert them to CRLF when files are checked out. |
| 219 | |
| 220 | If you simply want to have CRLF line endings in your working directory |
| 221 | regardless of the repository you are working with, you can set the |
| 222 | config variable "core.autocrlf" without using any attributes. |
| 223 | |
| 224 | ------------------------ |
| 225 | [core] |
| 226 | autocrlf = true |
| 227 | ------------------------ |
| 228 | |
| 229 | This does not force normalization of text files, but does ensure |
| 230 | that text files that you introduce to the repository have their line |
| 231 | endings normalized to LF when they are added, and that files that are |
| 232 | already normalized in the repository stay normalized. |
| 233 | |
| 234 | If you want to ensure that text files that any contributor introduces to |
| 235 | the repository have their line endings normalized, you can set the |
| 236 | `text` attribute to "auto" for _all_ files. |
| 237 | |
| 238 | ------------------------ |
| 239 | * text=auto |
| 240 | ------------------------ |
| 241 | |
| 242 | The attributes allow a fine-grained control, how the line endings |
| 243 | are converted. |
| 244 | Here is an example that will make Git normalize .txt, .vcproj and .sh |
| 245 | files, ensure that .vcproj files have CRLF and .sh files have LF in |
| 246 | the working directory, and prevent .jpg files from being normalized |
| 247 | regardless of their content. |
| 248 | |
| 249 | ------------------------ |
| 250 | * text=auto |
| 251 | *.txt text |
| 252 | *.vcproj text eol=crlf |
| 253 | *.sh text eol=lf |
| 254 | *.jpg -text |
| 255 | ------------------------ |
| 256 | |
| 257 | NOTE: When `text=auto` conversion is enabled in a cross-platform |
| 258 | project using push and pull to a central repository the text files |
| 259 | containing CRLFs should be normalized. |
| 260 | |
| 261 | From a clean working directory: |
| 262 | |
| 263 | ------------------------------------------------- |
| 264 | $ echo "* text=auto" >.gitattributes |
| 265 | $ git add --renormalize . |
| 266 | $ git status # Show files that will be normalized |
| 267 | $ git commit -m "Introduce end-of-line normalization" |
| 268 | ------------------------------------------------- |
| 269 | |
| 270 | If any files that should not be normalized show up in 'git status', |
| 271 | unset their `text` attribute before running 'git add -u'. |
| 272 | |
| 273 | ------------------------ |
| 274 | manual.pdf -text |
| 275 | ------------------------ |
| 276 | |
| 277 | Conversely, text files that Git does not detect can have normalization |
| 278 | enabled manually. |
| 279 | |
| 280 | ------------------------ |
| 281 | weirdchars.txt text |
| 282 | ------------------------ |
| 283 | |
| 284 | If `core.safecrlf` is set to "true" or "warn", Git verifies if |
| 285 | the conversion is reversible for the current setting of |
| 286 | `core.autocrlf`. For "true", Git rejects irreversible |
| 287 | conversions; for "warn", Git only prints a warning but accepts |
| 288 | an irreversible conversion. The safety triggers to prevent such |
| 289 | a conversion done to the files in the work tree, but there are a |
| 290 | few exceptions. Even though... |
| 291 | |
| 292 | - 'git add' itself does not touch the files in the work tree, the |
| 293 | next checkout would, so the safety triggers; |
| 294 | |
| 295 | - 'git apply' to update a text file with a patch does touch the files |
| 296 | in the work tree, but the operation is about text files and CRLF |
| 297 | conversion is about fixing the line ending inconsistencies, so the |
| 298 | safety does not trigger; |
| 299 | |
| 300 | - 'git diff' itself does not touch the files in the work tree, it is |
| 301 | often run to inspect the changes you intend to next 'git add'. To |
| 302 | catch potential problems early, safety triggers. |
| 303 | |
| 304 | |
| 305 | `working-tree-encoding` |
| 306 | ^^^^^^^^^^^^^^^^^^^^^^^ |
| 307 | |
| 308 | Git recognizes files encoded in ASCII or one of its supersets (e.g. |
| 309 | UTF-8, ISO-8859-1, ...) as text files. Files encoded in certain other |
| 310 | encodings (e.g. UTF-16) are interpreted as binary and consequently |
| 311 | built-in Git text processing tools (e.g. 'git diff') as well as most Git |
| 312 | web front ends do not visualize the contents of these files by default. |
| 313 | |
| 314 | In these cases you can tell Git the encoding of a file in the working |
| 315 | directory with the `working-tree-encoding` attribute. If a file with this |
| 316 | attribute is added to Git, then Git re-encodes the content from the |
| 317 | specified encoding to UTF-8. Finally, Git stores the UTF-8 encoded |
| 318 | content in its internal data structure (called "the index"). On checkout |
| 319 | the content is re-encoded back to the specified encoding. |
| 320 | |
| 321 | Please note that using the `working-tree-encoding` attribute may have a |
| 322 | number of pitfalls: |
| 323 | |
| 324 | - Alternative Git implementations (e.g. JGit or libgit2) and older Git |
| 325 | versions (as of March 2018) do not support the `working-tree-encoding` |
| 326 | attribute. If you decide to use the `working-tree-encoding` attribute |
| 327 | in your repository, then it is strongly recommended to ensure that all |
| 328 | clients working with the repository support it. |
| 329 | + |
| 330 | For example, Microsoft Visual Studio resources files (`*.rc`) or |
| 331 | PowerShell script files (`*.ps1`) are sometimes encoded in UTF-16. |
| 332 | If you declare `*.ps1` as files as UTF-16 and you add `foo.ps1` with |
| 333 | a `working-tree-encoding` enabled Git client, then `foo.ps1` will be |
| 334 | stored as UTF-8 internally. A client without `working-tree-encoding` |
| 335 | support will checkout `foo.ps1` as UTF-8 encoded file. This will |
| 336 | typically cause trouble for the users of this file. |
| 337 | + |
| 338 | If a Git client that does not support the `working-tree-encoding` |
| 339 | attribute adds a new file `bar.ps1`, then `bar.ps1` will be |
| 340 | stored "as-is" internally (in this example probably as UTF-16). |
| 341 | A client with `working-tree-encoding` support will interpret the |
| 342 | internal contents as UTF-8 and try to convert it to UTF-16 on checkout. |
| 343 | That operation will fail and cause an error. |
| 344 | |
| 345 | - Reencoding content to non-UTF encodings can cause errors as the |
| 346 | conversion might not be UTF-8 round trip safe. If you suspect your |
| 347 | encoding to not be round trip safe, then add it to |
| 348 | `core.checkRoundtripEncoding` to make Git check the round trip |
| 349 | encoding (see linkgit:git-config[1]). SHIFT-JIS (Japanese character |
| 350 | set) is known to have round trip issues with UTF-8 and is checked by |
| 351 | default. |
| 352 | |
| 353 | - Reencoding content requires resources that might slow down certain |
| 354 | Git operations (e.g 'git checkout' or 'git add'). |
| 355 | |
| 356 | Use the `working-tree-encoding` attribute only if you cannot store a file |
| 357 | in UTF-8 encoding and if you want Git to be able to process the content |
| 358 | as text. |
| 359 | |
| 360 | As an example, use the following attributes if your '*.ps1' files are |
| 361 | UTF-16 encoded with byte order mark (BOM) and you want Git to perform |
| 362 | automatic line ending conversion based on your platform. |
| 363 | |
| 364 | ------------------------ |
| 365 | *.ps1 text working-tree-encoding=UTF-16 |
| 366 | ------------------------ |
| 367 | |
| 368 | Use the following attributes if your '*.ps1' files are UTF-16 little |
| 369 | endian encoded without BOM and you want Git to use Windows line endings |
| 370 | in the working directory (use `UTF-16LE-BOM` instead of `UTF-16LE` if |
| 371 | you want UTF-16 little endian with BOM). |
| 372 | Please note, it is highly recommended to |
| 373 | explicitly define the line endings with `eol` if the `working-tree-encoding` |
| 374 | attribute is used to avoid ambiguity. |
| 375 | |
| 376 | ------------------------ |
| 377 | *.ps1 text working-tree-encoding=UTF-16LE eol=crlf |
| 378 | ------------------------ |
| 379 | |
| 380 | You can get a list of all available encodings on your platform with the |
| 381 | following command: |
| 382 | |
| 383 | ------------------------ |
| 384 | iconv --list |
| 385 | ------------------------ |
| 386 | |
| 387 | If you do not know the encoding of a file, then you can use the `file` |
| 388 | command to guess the encoding: |
| 389 | |
| 390 | ------------------------ |
| 391 | file foo.ps1 |
| 392 | ------------------------ |
| 393 | |
| 394 | |
| 395 | `ident` |
| 396 | ^^^^^^^ |
| 397 | |
| 398 | When the attribute `ident` is set for a path, Git replaces |
| 399 | `$Id$` in the blob object with `$Id:`, followed by the |
| 400 | 40-character hexadecimal blob object name, followed by a dollar |
| 401 | sign `$` upon checkout. Any byte sequence that begins with |
| 402 | `$Id:` and ends with `$` in the worktree file is replaced |
| 403 | with `$Id$` upon check-in. |
| 404 | |
| 405 | |
| 406 | `filter` |
| 407 | ^^^^^^^^ |
| 408 | |
| 409 | A `filter` attribute can be set to a string value that names a |
| 410 | filter driver specified in the configuration. |
| 411 | |
| 412 | A filter driver consists of a `clean` command and a `smudge` |
| 413 | command, either of which can be left unspecified. Upon |
| 414 | checkout, when the `smudge` command is specified, the command is |
| 415 | fed the blob object from its standard input, and its standard |
| 416 | output is used to update the worktree file. Similarly, the |
| 417 | `clean` command is used to convert the contents of worktree file |
| 418 | upon checkin. By default these commands process only a single |
| 419 | blob and terminate. If a long running `process` filter is used |
| 420 | in place of `clean` and/or `smudge` filters, then Git can process |
| 421 | all blobs with a single filter command invocation for the entire |
| 422 | life of a single Git command, for example `git add --all`. If a |
| 423 | long running `process` filter is configured then it always takes |
| 424 | precedence over a configured single blob filter. See section |
| 425 | below for the description of the protocol used to communicate with |
| 426 | a `process` filter. |
| 427 | |
| 428 | One use of the content filtering is to massage the content into a shape |
| 429 | that is more convenient for the platform, filesystem, and the user to use. |
| 430 | For this mode of operation, the key phrase here is "more convenient" and |
| 431 | not "turning something unusable into usable". In other words, the intent |
| 432 | is that if someone unsets the filter driver definition, or does not have |
| 433 | the appropriate filter program, the project should still be usable. |
| 434 | |
| 435 | Another use of the content filtering is to store the content that cannot |
| 436 | be directly used in the repository (e.g. a UUID that refers to the true |
| 437 | content stored outside Git, or an encrypted content) and turn it into a |
| 438 | usable form upon checkout (e.g. download the external content, or decrypt |
| 439 | the encrypted content). |
| 440 | |
| 441 | These two filters behave differently, and by default, a filter is taken as |
| 442 | the former, massaging the contents into more convenient shape. A missing |
| 443 | filter driver definition in the config, or a filter driver that exits with |
| 444 | a non-zero status, is not an error but makes the filter a no-op passthru. |
| 445 | |
| 446 | You can declare that a filter turns a content that by itself is unusable |
| 447 | into a usable content by setting the filter.<driver>.required configuration |
| 448 | variable to `true`. |
| 449 | |
| 450 | Note: Whenever the clean filter is changed, the repo should be renormalized: |
| 451 | $ git add --renormalize . |
| 452 | |
| 453 | For example, in .gitattributes, you would assign the `filter` |
| 454 | attribute for paths. |
| 455 | |
| 456 | ------------------------ |
| 457 | *.c filter=indent |
| 458 | ------------------------ |
| 459 | |
| 460 | Then you would define a "filter.indent.clean" and "filter.indent.smudge" |
| 461 | configuration in your .git/config to specify a pair of commands to |
| 462 | modify the contents of C programs when the source files are checked |
| 463 | in ("clean" is run) and checked out (no change is made because the |
| 464 | command is "cat"). |
| 465 | |
| 466 | ------------------------ |
| 467 | [filter "indent"] |
| 468 | clean = indent |
| 469 | smudge = cat |
| 470 | ------------------------ |
| 471 | |
| 472 | For best results, `clean` should not alter its output further if it is |
| 473 | run twice ("clean->clean" should be equivalent to "clean"), and |
| 474 | multiple `smudge` commands should not alter `clean`'s output |
| 475 | ("smudge->smudge->clean" should be equivalent to "clean"). See the |
| 476 | section on merging below. |
| 477 | |
| 478 | The "indent" filter is well-behaved in this regard: it will not modify |
| 479 | input that is already correctly indented. In this case, the lack of a |
| 480 | smudge filter means that the clean filter _must_ accept its own output |
| 481 | without modifying it. |
| 482 | |
| 483 | If a filter _must_ succeed in order to make the stored contents usable, |
| 484 | you can declare that the filter is `required`, in the configuration: |
| 485 | |
| 486 | ------------------------ |
| 487 | [filter "crypt"] |
| 488 | clean = openssl enc ... |
| 489 | smudge = openssl enc -d ... |
| 490 | required |
| 491 | ------------------------ |
| 492 | |
| 493 | Sequence "%f" on the filter command line is replaced with the name of |
| 494 | the file the filter is working on. A filter might use this in keyword |
| 495 | substitution. For example: |
| 496 | |
| 497 | ------------------------ |
| 498 | [filter "p4"] |
| 499 | clean = git-p4-filter --clean %f |
| 500 | smudge = git-p4-filter --smudge %f |
| 501 | ------------------------ |
| 502 | |
| 503 | Note that "%f" is the name of the path that is being worked on. Depending |
| 504 | on the version that is being filtered, the corresponding file on disk may |
| 505 | not exist, or may have different contents. So, smudge and clean commands |
| 506 | should not try to access the file on disk, but only act as filters on the |
| 507 | content provided to them on standard input. |
| 508 | |
| 509 | Long Running Filter Process |
| 510 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 511 | |
| 512 | If the filter command (a string value) is defined via |
| 513 | `filter.<driver>.process` then Git can process all blobs with a |
| 514 | single filter invocation for the entire life of a single Git |
| 515 | command. This is achieved by using the long-running process protocol |
| 516 | (described in Documentation/technical/long-running-process-protocol.adoc). |
| 517 | |
| 518 | When Git encounters the first file that needs to be cleaned or smudged, |
| 519 | it starts the filter and performs the handshake. In the handshake, the |
| 520 | welcome message sent by Git is "git-filter-client", only version 2 is |
| 521 | supported, and the supported capabilities are "clean", "smudge", and |
| 522 | "delay". |
| 523 | |
| 524 | Afterwards Git sends a list of "key=value" pairs terminated with |
| 525 | a flush packet. The list will contain at least the filter command |
| 526 | (based on the supported capabilities) and the pathname of the file |
| 527 | to filter relative to the repository root. Right after the flush packet |
| 528 | Git sends the content split in zero or more pkt-line packets and a |
| 529 | flush packet to terminate content. Please note, that the filter |
| 530 | must not send any response before it received the content and the |
| 531 | final flush packet. Also note that the "value" of a "key=value" pair |
| 532 | can contain the "=" character whereas the key would never contain |
| 533 | that character. |
| 534 | |
| 535 | ----------------------- |
| 536 | packet: git> command=smudge |
| 537 | packet: git> pathname=path/testfile.dat |
| 538 | packet: git> 0000 |
| 539 | packet: git> CONTENT |
| 540 | packet: git> 0000 |
| 541 | ----------------------- |
| 542 | |
| 543 | The filter is expected to respond with a list of "key=value" pairs |
| 544 | terminated with a flush packet. If the filter does not experience |
| 545 | problems then the list must contain a "success" status. Right after |
| 546 | these packets the filter is expected to send the content in zero |
| 547 | or more pkt-line packets and a flush packet at the end. Finally, a |
| 548 | second list of "key=value" pairs terminated with a flush packet |
| 549 | is expected. The filter can change the status in the second list |
| 550 | or keep the status as is with an empty list. Please note that the |
| 551 | empty list must be terminated with a flush packet regardless. |
| 552 | |
| 553 | ------------------------ |
| 554 | packet: git< status=success |
| 555 | packet: git< 0000 |
| 556 | packet: git< SMUDGED_CONTENT |
| 557 | packet: git< 0000 |
| 558 | packet: git< 0000 # empty list, keep "status=success" unchanged! |
| 559 | ------------------------ |
| 560 | |
| 561 | If the result content is empty then the filter is expected to respond |
| 562 | with a "success" status and a flush packet to signal the empty content. |
| 563 | |
| 564 | ------------------------ |
| 565 | packet: git< status=success |
| 566 | packet: git< 0000 |
| 567 | packet: git< 0000 # empty content! |
| 568 | packet: git< 0000 # empty list, keep "status=success" unchanged! |
| 569 | ------------------------ |
| 570 | |
| 571 | In case the filter cannot or does not want to process the content, |
| 572 | it is expected to respond with an "error" status. |
| 573 | |
| 574 | ----------------------- |
| 575 | packet: git< status=error |
| 576 | packet: git< 0000 |
| 577 | ----------------------- |
| 578 | |
| 579 | If the filter experiences an error during processing, then it can |
| 580 | send the status "error" after the content was (partially or |
| 581 | completely) sent. |
| 582 | |
| 583 | ------------------------ |
| 584 | packet: git< status=success |
| 585 | packet: git< 0000 |
| 586 | packet: git< HALF_WRITTEN_ERRONEOUS_CONTENT |
| 587 | packet: git< 0000 |
| 588 | packet: git< status=error |
| 589 | packet: git< 0000 |
| 590 | ------------------------ |
| 591 | |
| 592 | In case the filter cannot or does not want to process the content |
| 593 | as well as any future content for the lifetime of the Git process, |
| 594 | then it is expected to respond with an "abort" status at any point |
| 595 | in the protocol. |
| 596 | |
| 597 | ----------------------- |
| 598 | packet: git< status=abort |
| 599 | packet: git< 0000 |
| 600 | ----------------------- |
| 601 | |
| 602 | Git neither stops nor restarts the filter process in case the |
| 603 | "error"/"abort" status is set. However, Git sets its exit code |
| 604 | according to the `filter.<driver>.required` flag, mimicking the |
| 605 | behavior of the `filter.<driver>.clean` / `filter.<driver>.smudge` |
| 606 | mechanism. |
| 607 | |
| 608 | If the filter dies during the communication or does not adhere to |
| 609 | the protocol then Git will stop the filter process and restart it |
| 610 | with the next file that needs to be processed. Depending on the |
| 611 | `filter.<driver>.required` flag Git will interpret that as error. |
| 612 | |
| 613 | Delay |
| 614 | ^^^^^ |
| 615 | |
| 616 | If the filter supports the "delay" capability, then Git can send the |
| 617 | flag "can-delay" after the filter command and pathname. This flag |
| 618 | denotes that the filter can delay filtering the current blob (e.g. to |
| 619 | compensate network latencies) by responding with no content but with |
| 620 | the status "delayed" and a flush packet. |
| 621 | |
| 622 | ----------------------- |
| 623 | packet: git> command=smudge |
| 624 | packet: git> pathname=path/testfile.dat |
| 625 | packet: git> can-delay=1 |
| 626 | packet: git> 0000 |
| 627 | packet: git> CONTENT |
| 628 | packet: git> 0000 |
| 629 | packet: git< status=delayed |
| 630 | packet: git< 0000 |
| 631 | ----------------------- |
| 632 | |
| 633 | If the filter supports the "delay" capability then it must support the |
| 634 | "list_available_blobs" command. If Git sends this command, then the |
| 635 | filter is expected to return a list of pathnames representing blobs |
| 636 | that have been delayed earlier and are now available. |
| 637 | The list must be terminated with a flush packet followed |
| 638 | by a "success" status that is also terminated with a flush packet. If |
| 639 | no blobs for the delayed paths are available, yet, then the filter is |
| 640 | expected to block the response until at least one blob becomes |
| 641 | available. The filter can tell Git that it has no more delayed blobs |
| 642 | by sending an empty list. As soon as the filter responds with an empty |
| 643 | list, Git stops asking. All blobs that Git has not received at this |
| 644 | point are considered missing and will result in an error. |
| 645 | |
| 646 | ------------------------ |
| 647 | packet: git> command=list_available_blobs |
| 648 | packet: git> 0000 |
| 649 | packet: git< pathname=path/testfile.dat |
| 650 | packet: git< pathname=path/otherfile.dat |
| 651 | packet: git< 0000 |
| 652 | packet: git< status=success |
| 653 | packet: git< 0000 |
| 654 | ------------------------ |
| 655 | |
| 656 | |
| 657 | After Git received the pathnames, it will request the corresponding |
| 658 | blobs again. These requests contain a pathname and an empty content |
| 659 | section. The filter is expected to respond with the smudged content |
| 660 | in the usual way as explained above. |
| 661 | |
| 662 | ------------------------ |
| 663 | packet: git> command=smudge |
| 664 | packet: git> pathname=path/testfile.dat |
| 665 | packet: git> 0000 |
| 666 | packet: git> 0000 # empty content! |
| 667 | packet: git< status=success |
| 668 | packet: git< 0000 |
| 669 | packet: git< SMUDGED_CONTENT |
| 670 | packet: git< 0000 |
| 671 | packet: git< 0000 # empty list, keep "status=success" unchanged! |
| 672 | ------------------------ |
| 673 | |
| 674 | Example |
| 675 | ^^^^^^^ |
| 676 | |
| 677 | A long running filter demo implementation can be found in |
| 678 | `contrib/long-running-filter/example.pl` located in the Git |
| 679 | core repository. If you develop your own long running filter |
| 680 | process then the `GIT_TRACE_PACKET` environment variables can be |
| 681 | very helpful for debugging (see linkgit:git[1]). |
| 682 | |
| 683 | Please note that you cannot use an existing `filter.<driver>.clean` |
| 684 | or `filter.<driver>.smudge` command with `filter.<driver>.process` |
| 685 | because the former two use a different inter process communication |
| 686 | protocol than the latter one. |
| 687 | |
| 688 | |
| 689 | Interaction between checkin/checkout attributes |
| 690 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 691 | |
| 692 | In the check-in codepath, the worktree file is first converted |
| 693 | with `filter` driver (if specified and corresponding driver |
| 694 | defined), then the result is processed with `ident` (if |
| 695 | specified), and then finally with `text` (again, if specified |
| 696 | and applicable). |
| 697 | |
| 698 | In the check-out codepath, the blob content is first converted |
| 699 | with `text`, and then `ident` and fed to `filter`. |
| 700 | |
| 701 | |
| 702 | Merging branches with differing checkin/checkout attributes |
| 703 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 704 | |
| 705 | If you have added attributes to a file that cause the canonical |
| 706 | repository format for that file to change, such as adding a |
| 707 | clean/smudge filter or text/eol/ident attributes, merging anything |
| 708 | where the attribute is not in place would normally cause merge |
| 709 | conflicts. |
| 710 | |
| 711 | To prevent these unnecessary merge conflicts, Git can be told to run a |
| 712 | virtual check-out and check-in of all three stages of each file that |
| 713 | needs a three-way content merge, by setting the `merge.renormalize` |
| 714 | configuration variable. This prevents changes caused by check-in |
| 715 | conversion from causing spurious merge conflicts when a converted file |
| 716 | is merged with an unconverted file. |
| 717 | |
| 718 | As long as a "smudge->clean" results in the same output as a "clean" |
| 719 | even on files that are already smudged, this strategy will |
| 720 | automatically resolve all filter-related conflicts. Filters that do |
| 721 | not act in this way may cause additional merge conflicts that must be |
| 722 | resolved manually. |
| 723 | |
| 724 | |
| 725 | Generating diff text |
| 726 | ~~~~~~~~~~~~~~~~~~~~ |
| 727 | |
| 728 | `diff` |
| 729 | ^^^^^^ |
| 730 | |
| 731 | The attribute `diff` affects how Git generates diffs for particular |
| 732 | files. It can tell Git whether to generate a textual patch for the path |
| 733 | or to treat the path as a binary file. It can also affect what line is |
| 734 | shown on the hunk header `@@ -k,l +n,m @@` line, tell Git to use an |
| 735 | external command to generate the diff, or ask Git to convert binary |
| 736 | files to a text format before generating the diff. |
| 737 | |
| 738 | Set:: |
| 739 | |
| 740 | A path to which the `diff` attribute is set is treated |
| 741 | as text, even when they contain byte values that |
| 742 | normally never appear in text files, such as NUL. |
| 743 | |
| 744 | Unset:: |
| 745 | |
| 746 | A path to which the `diff` attribute is unset will |
| 747 | generate `Binary files differ` (or a binary patch, if |
| 748 | binary patches are enabled). |
| 749 | |
| 750 | Unspecified:: |
| 751 | |
| 752 | A path to which the `diff` attribute is unspecified |
| 753 | first gets its contents inspected, and if it looks like |
| 754 | text and is smaller than core.bigFileThreshold, it is treated |
| 755 | as text. Otherwise it would generate `Binary files differ`. |
| 756 | |
| 757 | String:: |
| 758 | |
| 759 | Diff is shown using the specified diff driver. Each driver may |
| 760 | specify one or more options, as described in the following |
| 761 | section. The options for the diff driver "foo" are defined |
| 762 | by the configuration variables in the "diff.foo" section of the |
| 763 | Git config file. |
| 764 | |
| 765 | |
| 766 | Defining an external diff driver |
| 767 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 768 | |
| 769 | The definition of a diff driver is done in `gitconfig`, not |
| 770 | `gitattributes` file, so strictly speaking this manual page is a |
| 771 | wrong place to talk about it. However... |
| 772 | |
| 773 | To define an external diff driver `jcdiff`, add a section to your |
| 774 | `$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: |
| 775 | |
| 776 | ---------------------------------------------------------------- |
| 777 | [diff "jcdiff"] |
| 778 | command = j-c-diff |
| 779 | ---------------------------------------------------------------- |
| 780 | |
| 781 | When Git needs to show you a diff for the path with `diff` |
| 782 | attribute set to `jcdiff`, it calls the command you specified |
| 783 | with the above configuration, i.e. `j-c-diff`, with 7 |
| 784 | parameters, just like `GIT_EXTERNAL_DIFF` program is called. |
| 785 | See linkgit:git[1] for details. |
| 786 | |
| 787 | If the program is able to ignore certain changes (similar to |
| 788 | `git diff --ignore-space-change`), then also set the option |
| 789 | `trustExitCode` to true. It is then expected to return exit code 1 if |
| 790 | it finds significant changes and 0 if it doesn't. |
| 791 | |
| 792 | Setting the internal diff algorithm |
| 793 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 794 | |
| 795 | The diff algorithm can be set through the `diff.algorithm` config key, but |
| 796 | sometimes it may be helpful to set the diff algorithm per path. For example, |
| 797 | one may want to use the `minimal` diff algorithm for .json files, and the |
| 798 | `histogram` for .c files, and so on without having to pass in the algorithm |
| 799 | through the command line each time. |
| 800 | |
| 801 | First, in `.gitattributes`, assign the `diff` attribute for paths. |
| 802 | |
| 803 | ------------------------ |
| 804 | *.json diff=<name> |
| 805 | ------------------------ |
| 806 | |
| 807 | Then, define a "diff.<name>.algorithm" configuration to specify the diff |
| 808 | algorithm, choosing from `myers`, `patience`, `minimal`, or `histogram`. |
| 809 | |
| 810 | ---------------------------------------------------------------- |
| 811 | [diff "<name>"] |
| 812 | algorithm = histogram |
| 813 | ---------------------------------------------------------------- |
| 814 | |
| 815 | This diff algorithm applies to user facing diff output like git-diff(1), |
| 816 | git-show(1) and is used for the `--stat` output as well. The merge machinery |
| 817 | will not use the diff algorithm set through this method. |
| 818 | |
| 819 | NOTE: If `diff.<name>.command` is defined for path with the |
| 820 | `diff=<name>` attribute, it is executed as an external diff driver |
| 821 | (see above), and adding `diff.<name>.algorithm` has no effect, as the |
| 822 | algorithm is not passed to the external diff driver. |
| 823 | |
| 824 | Defining a custom hunk-header |
| 825 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 826 | |
| 827 | Each group of changes (called a "hunk") in the textual diff output |
| 828 | is prefixed with a line of the form: |
| 829 | |
| 830 | @@ -k,l +n,m @@ TEXT |
| 831 | |
| 832 | This is called a 'hunk header'. The "TEXT" portion is by default a line |
| 833 | that begins with an alphabet, an underscore or a dollar sign; this |
| 834 | matches what GNU 'diff -p' output uses. This default selection however |
| 835 | is not suited for some contents, and you can use a customized pattern |
| 836 | to make a selection. |
| 837 | |
| 838 | First, in .gitattributes, you would assign the `diff` attribute |
| 839 | for paths. |
| 840 | |
| 841 | ------------------------ |
| 842 | *.tex diff=tex |
| 843 | ------------------------ |
| 844 | |
| 845 | Then, you would define a "diff.tex.xfuncname" configuration to |
| 846 | specify a regular expression that matches a line that you would |
| 847 | want to appear as the hunk header "TEXT". Add a section to your |
| 848 | `$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: |
| 849 | |
| 850 | ------------------------ |
| 851 | [diff "tex"] |
| 852 | xfuncname = "^(\\\\(sub)*section\\{.*)$" |
| 853 | ------------------------ |
| 854 | |
| 855 | Note. A single level of backslashes are eaten by the |
| 856 | configuration file parser, so you would need to double the |
| 857 | backslashes; the pattern above picks a line that begins with a |
| 858 | backslash, and zero or more occurrences of `sub` followed by |
| 859 | `section` followed by open brace, to the end of line. |
| 860 | |
| 861 | There are a few built-in patterns to make this easier, and `tex` |
| 862 | is one of them, so you do not have to write the above in your |
| 863 | configuration file (you still need to enable this with the |
| 864 | attribute mechanism, via `.gitattributes`). The following built in |
| 865 | patterns are available: |
| 866 | |
| 867 | - `ada` suitable for source code in the Ada language. |
| 868 | |
| 869 | - `bash` suitable for source code in the Bourne-Again SHell language. |
| 870 | Covers a superset of POSIX shell function definitions. |
| 871 | |
| 872 | - `bibtex` suitable for files with BibTeX coded references. |
| 873 | |
| 874 | - `cpp` suitable for source code in the C and C++ languages. |
| 875 | |
| 876 | - `csharp` suitable for source code in the C# language. |
| 877 | |
| 878 | - `css` suitable for cascading style sheets. |
| 879 | |
| 880 | - `dts` suitable for devicetree (DTS) files. |
| 881 | |
| 882 | - `elixir` suitable for source code in the Elixir language. |
| 883 | |
| 884 | - `fortran` suitable for source code in the Fortran language. |
| 885 | |
| 886 | - `fountain` suitable for Fountain documents. |
| 887 | |
| 888 | - `golang` suitable for source code in the Go language. |
| 889 | |
| 890 | - `html` suitable for HTML/XHTML documents. |
| 891 | |
| 892 | - `java` suitable for source code in the Java language. |
| 893 | |
| 894 | - `kotlin` suitable for source code in the Kotlin language. |
| 895 | |
| 896 | - `markdown` suitable for Markdown documents. |
| 897 | |
| 898 | - `matlab` suitable for source code in the MATLAB and Octave languages. |
| 899 | |
| 900 | - `objc` suitable for source code in the Objective-C language. |
| 901 | |
| 902 | - `pascal` suitable for source code in the Pascal/Delphi language. |
| 903 | |
| 904 | - `perl` suitable for source code in the Perl language. |
| 905 | |
| 906 | - `php` suitable for source code in the PHP language. |
| 907 | |
| 908 | - `python` suitable for source code in the Python language. |
| 909 | |
| 910 | - `ruby` suitable for source code in the Ruby language. |
| 911 | |
| 912 | - `rust` suitable for source code in the Rust language. |
| 913 | |
| 914 | - `scheme` suitable for source code in most Lisp dialects, |
| 915 | including Scheme, Emacs Lisp, Common Lisp, and Clojure. |
| 916 | |
| 917 | - `swift` suitable for source code in the Swift language. |
| 918 | |
| 919 | - `tex` suitable for source code for LaTeX documents. |
| 920 | |
| 921 | |
| 922 | Customizing word diff |
| 923 | ^^^^^^^^^^^^^^^^^^^^^ |
| 924 | |
| 925 | You can customize the rules that `git diff --word-diff` uses to |
| 926 | split words in a line, by specifying an appropriate regular expression |
| 927 | in the "diff.*.wordRegex" configuration variable. For example, in TeX |
| 928 | a backslash followed by a sequence of letters forms a command, but |
| 929 | several such commands can be run together without intervening |
| 930 | whitespace. To separate them, use a regular expression in your |
| 931 | `$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: |
| 932 | |
| 933 | ------------------------ |
| 934 | [diff "tex"] |
| 935 | wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+" |
| 936 | ------------------------ |
| 937 | |
| 938 | A built-in pattern is provided for all languages listed in the |
| 939 | previous section. |
| 940 | |
| 941 | |
| 942 | Performing text diffs of binary files |
| 943 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 944 | |
| 945 | Sometimes it is desirable to see the diff of a text-converted |
| 946 | version of some binary files. For example, a word processor |
| 947 | document can be converted to an ASCII text representation, and |
| 948 | the diff of the text shown. Even though this conversion loses |
| 949 | some information, the resulting diff is useful for human |
| 950 | viewing (but cannot be applied directly). |
| 951 | |
| 952 | The `textconv` config option is used to define a program for |
| 953 | performing such a conversion. The program should take a single |
| 954 | argument, the name of a file to convert, and produce the |
| 955 | resulting text on stdout. |
| 956 | |
| 957 | For example, to show the diff of the exif information of a |
| 958 | file instead of the binary information (assuming you have the |
| 959 | exif tool installed), add the following section to your |
| 960 | `$GIT_DIR/config` file (or `$HOME/.gitconfig` file): |
| 961 | |
| 962 | ------------------------ |
| 963 | [diff "jpg"] |
| 964 | textconv = exif |
| 965 | ------------------------ |
| 966 | |
| 967 | NOTE: The text conversion is generally a one-way conversion; |
| 968 | in this example, we lose the actual image contents and focus |
| 969 | just on the text data. This means that diffs generated by |
| 970 | textconv are _not_ suitable for applying. For this reason, |
| 971 | only `git diff` and the `git log` family of commands (i.e., |
| 972 | log, whatchanged, show) will perform text conversion. `git |
| 973 | format-patch` will never generate this output. If you want to |
| 974 | send somebody a text-converted diff of a binary file (e.g., |
| 975 | because it quickly conveys the changes you have made), you |
| 976 | should generate it separately and send it as a comment _in |
| 977 | addition to_ the usual binary diff that you might send. |
| 978 | |
| 979 | Because text conversion can be slow, especially when doing a |
| 980 | large number of them with `git log -p`, Git provides a mechanism |
| 981 | to cache the output and use it in future diffs. To enable |
| 982 | caching, set the "cachetextconv" variable in your diff driver's |
| 983 | config. For example: |
| 984 | |
| 985 | ------------------------ |
| 986 | [diff "jpg"] |
| 987 | textconv = exif |
| 988 | cachetextconv = true |
| 989 | ------------------------ |
| 990 | |
| 991 | This will cache the result of running "exif" on each blob |
| 992 | indefinitely. If you change the textconv config variable for a |
| 993 | diff driver, Git will automatically invalidate the cache entries |
| 994 | and re-run the textconv filter. If you want to invalidate the |
| 995 | cache manually (e.g., because your version of "exif" was updated |
| 996 | and now produces better output), you can remove the cache |
| 997 | manually with `git update-ref -d refs/notes/textconv/jpg` (where |
| 998 | "jpg" is the name of the diff driver, as in the example above). |
| 999 | |
| 1000 | Choosing textconv versus external diff |
| 1001 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 1002 | |
| 1003 | If you want to show differences between binary or specially-formatted |
| 1004 | blobs in your repository, you can choose to use either an external diff |
| 1005 | command, or to use textconv to convert them to a diff-able text format. |
| 1006 | Which method you choose depends on your exact situation. |
| 1007 | |
| 1008 | The advantage of using an external diff command is flexibility. You are |
| 1009 | not bound to find line-oriented changes, nor is it necessary for the |
| 1010 | output to resemble unified diff. You are free to locate and report |
| 1011 | changes in the most appropriate way for your data format. |
| 1012 | |
| 1013 | A textconv, by comparison, is much more limiting. You provide a |
| 1014 | transformation of the data into a line-oriented text format, and Git |
| 1015 | uses its regular diff tools to generate the output. There are several |
| 1016 | advantages to choosing this method: |
| 1017 | |
| 1018 | 1. Ease of use. It is often much simpler to write a binary to text |
| 1019 | transformation than it is to perform your own diff. In many cases, |
| 1020 | existing programs can be used as textconv filters (e.g., exif, |
| 1021 | odt2txt). |
| 1022 | |
| 1023 | 2. Git diff features. By performing only the transformation step |
| 1024 | yourself, you can still utilize many of Git's diff features, |
| 1025 | including colorization, word-diff, and combined diffs for merges. |
| 1026 | |
| 1027 | 3. Caching. Textconv caching can speed up repeated diffs, such as those |
| 1028 | you might trigger by running `git log -p`. |
| 1029 | |
| 1030 | |
| 1031 | Marking files as binary |
| 1032 | ^^^^^^^^^^^^^^^^^^^^^^^ |
| 1033 | |
| 1034 | Git usually guesses correctly whether a blob contains text or binary |
| 1035 | data by examining the beginning of the contents. However, sometimes you |
| 1036 | may want to override its decision, either because a blob contains binary |
| 1037 | data later in the file, or because the content, while technically |
| 1038 | composed of text characters, is opaque to a human reader. For example, |
| 1039 | many postscript files contain only ASCII characters, but produce noisy |
| 1040 | and meaningless diffs. |
| 1041 | |
| 1042 | The simplest way to mark a file as binary is to unset the diff |
| 1043 | attribute in the `.gitattributes` file: |
| 1044 | |
| 1045 | ------------------------ |
| 1046 | *.ps -diff |
| 1047 | ------------------------ |
| 1048 | |
| 1049 | This will cause Git to generate `Binary files differ` (or a binary |
| 1050 | patch, if binary patches are enabled) instead of a regular diff. |
| 1051 | |
| 1052 | However, one may also want to specify other diff driver attributes. For |
| 1053 | example, you might want to use `textconv` to convert postscript files to |
| 1054 | an ASCII representation for human viewing, but otherwise treat them as |
| 1055 | binary files. You cannot specify both `-diff` and `diff=ps` attributes. |
| 1056 | The solution is to use the `diff.*.binary` config option: |
| 1057 | |
| 1058 | ------------------------ |
| 1059 | [diff "ps"] |
| 1060 | textconv = ps2ascii |
| 1061 | binary = true |
| 1062 | ------------------------ |
| 1063 | |
| 1064 | Performing a three-way merge |
| 1065 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 1066 | |
| 1067 | `merge` |
| 1068 | ^^^^^^^ |
| 1069 | |
| 1070 | The attribute `merge` affects how three versions of a file are |
| 1071 | merged when a file-level merge is necessary during `git merge`, |
| 1072 | and other commands such as `git revert` and `git cherry-pick`. |
| 1073 | |
| 1074 | Set:: |
| 1075 | |
| 1076 | Built-in 3-way merge driver is used to merge the |
| 1077 | contents in a way similar to 'merge' command of `RCS` |
| 1078 | suite. This is suitable for ordinary text files. |
| 1079 | |
| 1080 | Unset:: |
| 1081 | |
| 1082 | Take the version from the current branch as the |
| 1083 | tentative merge result, and declare that the merge has |
| 1084 | conflicts. This is suitable for binary files that do |
| 1085 | not have a well-defined merge semantics. |
| 1086 | |
| 1087 | Unspecified:: |
| 1088 | |
| 1089 | By default, this uses the same built-in 3-way merge |
| 1090 | driver as is the case when the `merge` attribute is set. |
| 1091 | However, the `merge.default` configuration variable can name |
| 1092 | different merge driver to be used with paths for which the |
| 1093 | `merge` attribute is unspecified. |
| 1094 | |
| 1095 | String:: |
| 1096 | |
| 1097 | 3-way merge is performed using the specified custom |
| 1098 | merge driver. The built-in 3-way merge driver can be |
| 1099 | explicitly specified by asking for "text" driver; the |
| 1100 | built-in "take the current branch" driver can be |
| 1101 | requested with "binary". |
| 1102 | |
| 1103 | |
| 1104 | Built-in merge drivers |
| 1105 | ^^^^^^^^^^^^^^^^^^^^^^ |
| 1106 | |
| 1107 | There are a few built-in low-level merge drivers defined that |
| 1108 | can be asked for via the `merge` attribute. |
| 1109 | |
| 1110 | text:: |
| 1111 | |
| 1112 | Usual 3-way file level merge for text files. Conflicted |
| 1113 | regions are marked with conflict markers `<<<<<<<`, |
| 1114 | `=======` and `>>>>>>>`. The version from your branch |
| 1115 | appears before the `=======` marker, and the version |
| 1116 | from the merged branch appears after the `=======` |
| 1117 | marker. |
| 1118 | |
| 1119 | binary:: |
| 1120 | |
| 1121 | Keep the version from your branch in the work tree, but |
| 1122 | leave the path in the conflicted state for the user to |
| 1123 | sort out. |
| 1124 | |
| 1125 | union:: |
| 1126 | |
| 1127 | Run 3-way file level merge for text files, but take |
| 1128 | lines from both versions, instead of leaving conflict |
| 1129 | markers. This tends to leave the added lines in the |
| 1130 | resulting file in random order and the user should |
| 1131 | verify the result. Do not use this if you do not |
| 1132 | understand the implications. |
| 1133 | |
| 1134 | |
| 1135 | Defining a custom merge driver |
| 1136 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 1137 | |
| 1138 | The definition of a merge driver is done in the `.git/config` |
| 1139 | file, not in the `gitattributes` file, so strictly speaking this |
| 1140 | manual page is a wrong place to talk about it. However... |
| 1141 | |
| 1142 | To define a custom merge driver `filfre`, add a section to your |
| 1143 | `$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this: |
| 1144 | |
| 1145 | ---------------------------------------------------------------- |
| 1146 | [merge "filfre"] |
| 1147 | name = feel-free merge driver |
| 1148 | driver = filfre %O %A %B %L %P |
| 1149 | recursive = binary |
| 1150 | ---------------------------------------------------------------- |
| 1151 | |
| 1152 | The `merge.*.name` variable gives the driver a human-readable |
| 1153 | name. |
| 1154 | |
| 1155 | The `merge.*.driver` variable's value is used to construct a |
| 1156 | command to run to common ancestor's version (`%O`), current |
| 1157 | version (`%A`) and the other branches' version (`%B`). These |
| 1158 | three tokens are replaced with the names of temporary files that |
| 1159 | hold the contents of these versions when the command line is |
| 1160 | built. Additionally, `%L` will be replaced with the conflict marker |
| 1161 | size (see below). |
| 1162 | |
| 1163 | The merge driver is expected to leave the result of the merge in |
| 1164 | the file named with `%A` by overwriting it, and exit with zero |
| 1165 | status if it managed to merge them cleanly, or non-zero if there |
| 1166 | were conflicts. When the driver crashes (e.g. killed by SEGV), |
| 1167 | it is expected to exit with non-zero status that are higher than |
| 1168 | 128, and in such a case, the merge results in a failure (which is |
| 1169 | different from producing a conflict). |
| 1170 | |
| 1171 | The `merge.*.recursive` variable specifies what other merge |
| 1172 | driver to use when the merge driver is called for an internal |
| 1173 | merge between common ancestors, when there are more than one. |
| 1174 | When left unspecified, the driver itself is used for both |
| 1175 | internal merge and the final merge. |
| 1176 | |
| 1177 | The merge driver can learn the pathname in which the merged result |
| 1178 | will be stored via placeholder `%P`. The conflict labels to be used |
| 1179 | for the common ancestor, local head and other head can be passed by |
| 1180 | using `%S`, `%X` and `%Y` respectively. |
| 1181 | |
| 1182 | `conflict-marker-size` |
| 1183 | ^^^^^^^^^^^^^^^^^^^^^^ |
| 1184 | |
| 1185 | This attribute controls the length of conflict markers left in |
| 1186 | the work tree file during a conflicted merge. Only a positive |
| 1187 | integer has a meaningful effect. |
| 1188 | |
| 1189 | For example, this line in `.gitattributes` can be used to tell the merge |
| 1190 | machinery to leave much longer (instead of the usual 7-character-long) |
| 1191 | conflict markers when merging the file `Documentation/git-merge.adoc` |
| 1192 | results in a conflict. |
| 1193 | |
| 1194 | ------------------------ |
| 1195 | Documentation/git-merge.adoc conflict-marker-size=32 |
| 1196 | ------------------------ |
| 1197 | |
| 1198 | |
| 1199 | Checking whitespace errors |
| 1200 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 1201 | |
| 1202 | `whitespace` |
| 1203 | ^^^^^^^^^^^^ |
| 1204 | |
| 1205 | The `core.whitespace` configuration variable allows you to define what |
| 1206 | 'diff' and 'apply' should consider whitespace errors for all paths in |
| 1207 | the project (See linkgit:git-config[1]). This attribute gives you finer |
| 1208 | control per path. |
| 1209 | |
| 1210 | Set:: |
| 1211 | |
| 1212 | Notice all types of potential whitespace errors known to Git. |
| 1213 | The tab width is taken from the value of the `core.whitespace` |
| 1214 | configuration variable. |
| 1215 | |
| 1216 | Unset:: |
| 1217 | |
| 1218 | Do not notice anything as error. |
| 1219 | |
| 1220 | Unspecified:: |
| 1221 | |
| 1222 | Use the value of the `core.whitespace` configuration variable to |
| 1223 | decide what to notice as error. |
| 1224 | |
| 1225 | String:: |
| 1226 | |
| 1227 | Specify a comma separated list of common whitespace problems to |
| 1228 | notice in the same format as the `core.whitespace` configuration |
| 1229 | variable. |
| 1230 | |
| 1231 | |
| 1232 | Creating an archive |
| 1233 | ~~~~~~~~~~~~~~~~~~~ |
| 1234 | |
| 1235 | `export-ignore` |
| 1236 | ^^^^^^^^^^^^^^^ |
| 1237 | |
| 1238 | Files and directories with the attribute `export-ignore` won't be added to |
| 1239 | archive files. |
| 1240 | |
| 1241 | `export-subst` |
| 1242 | ^^^^^^^^^^^^^^ |
| 1243 | |
| 1244 | If the attribute `export-subst` is set for a file then Git will expand |
| 1245 | several placeholders when adding this file to an archive. The |
| 1246 | expansion depends on the availability of a commit ID, i.e., if |
| 1247 | linkgit:git-archive[1] has been given a tree instead of a commit or a |
| 1248 | tag then no replacement will be done. The placeholders are the same |
| 1249 | as those for the option `--pretty=format:` of linkgit:git-log[1], |
| 1250 | except that they need to be wrapped like this: `$Format:PLACEHOLDERS$` |
| 1251 | in the file. E.g. the string `$Format:%H$` will be replaced by the |
| 1252 | commit hash. However, only one `%(describe)` placeholder is expanded |
| 1253 | per archive to avoid denial-of-service attacks. |
| 1254 | |
| 1255 | |
| 1256 | Packing objects |
| 1257 | ~~~~~~~~~~~~~~~ |
| 1258 | |
| 1259 | `delta` |
| 1260 | ^^^^^^^ |
| 1261 | |
| 1262 | Delta compression will not be attempted for blobs for paths with the |
| 1263 | attribute `delta` set to false. |
| 1264 | |
| 1265 | |
| 1266 | Viewing files in GUI tools |
| 1267 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 1268 | |
| 1269 | `encoding` |
| 1270 | ^^^^^^^^^^ |
| 1271 | |
| 1272 | The value of this attribute specifies the character encoding that should |
| 1273 | be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to |
| 1274 | display the contents of the relevant file. Note that due to performance |
| 1275 | considerations linkgit:gitk[1] does not use this attribute unless you |
| 1276 | manually enable per-file encodings in its options. |
| 1277 | |
| 1278 | If this attribute is not set or has an invalid value, the value of the |
| 1279 | `gui.encoding` configuration variable is used instead |
| 1280 | (See linkgit:git-config[1]). |
| 1281 | |
| 1282 | |
| 1283 | USING MACRO ATTRIBUTES |
| 1284 | ---------------------- |
| 1285 | |
| 1286 | You do not want any end-of-line conversions applied to, nor textual diffs |
| 1287 | produced for, any binary file you track. You would need to specify e.g. |
| 1288 | |
| 1289 | ------------ |
| 1290 | *.jpg -text -diff |
| 1291 | ------------ |
| 1292 | |
| 1293 | but that may become cumbersome, when you have many attributes. Using |
| 1294 | macro attributes, you can define an attribute that, when set, also |
| 1295 | sets or unsets a number of other attributes at the same time. The |
| 1296 | system knows a built-in macro attribute, `binary`: |
| 1297 | |
| 1298 | ------------ |
| 1299 | *.jpg binary |
| 1300 | ------------ |
| 1301 | |
| 1302 | Setting the "binary" attribute also unsets the "text" and "diff" |
| 1303 | attributes as above. Note that macro attributes can only be "Set", |
| 1304 | though setting one might have the effect of setting or unsetting other |
| 1305 | attributes or even returning other attributes to the "Unspecified" |
| 1306 | state. |
| 1307 | |
| 1308 | |
| 1309 | DEFINING MACRO ATTRIBUTES |
| 1310 | ------------------------- |
| 1311 | |
| 1312 | Custom macro attributes can be defined only in top-level gitattributes |
| 1313 | files (`$GIT_DIR/info/attributes`, the `.gitattributes` file at the |
| 1314 | top level of the working tree, or the global or system-wide |
| 1315 | gitattributes files), not in `.gitattributes` files in working tree |
| 1316 | subdirectories. The built-in macro attribute "binary" is equivalent |
| 1317 | to: |
| 1318 | |
| 1319 | ------------ |
| 1320 | [attr]binary -diff -merge -text |
| 1321 | ------------ |
| 1322 | |
| 1323 | NOTES |
| 1324 | ----- |
| 1325 | |
| 1326 | Git does not follow symbolic links when accessing a `.gitattributes` |
| 1327 | file in the working tree. This keeps behavior consistent when the file |
| 1328 | is accessed from the index or a tree versus from the filesystem. |
| 1329 | |
| 1330 | EXAMPLES |
| 1331 | -------- |
| 1332 | |
| 1333 | If you have these three `gitattributes` file: |
| 1334 | |
| 1335 | ---------------------------------------------------------------- |
| 1336 | (in $GIT_DIR/info/attributes) |
| 1337 | |
| 1338 | a* foo !bar -baz |
| 1339 | |
| 1340 | (in .gitattributes) |
| 1341 | abc foo bar baz |
| 1342 | |
| 1343 | (in t/.gitattributes) |
| 1344 | ab* merge=filfre |
| 1345 | abc -foo -bar |
| 1346 | *.c frotz |
| 1347 | ---------------------------------------------------------------- |
| 1348 | |
| 1349 | the attributes given to path `t/abc` are computed as follows: |
| 1350 | |
| 1351 | 1. By examining `t/.gitattributes` (which is in the same |
| 1352 | directory as the path in question), Git finds that the first |
| 1353 | line matches. `merge` attribute is set. It also finds that |
| 1354 | the second line matches, and attributes `foo` and `bar` |
| 1355 | are unset. |
| 1356 | |
| 1357 | 2. Then it examines `.gitattributes` (which is in the parent |
| 1358 | directory), and finds that the first line matches, but |
| 1359 | `t/.gitattributes` file already decided how `merge`, `foo` |
| 1360 | and `bar` attributes should be given to this path, so it |
| 1361 | leaves `foo` and `bar` unset. Attribute `baz` is set. |
| 1362 | |
| 1363 | 3. Finally it examines `$GIT_DIR/info/attributes`. This file |
| 1364 | is used to override the in-tree settings. The first line is |
| 1365 | a match, and `foo` is set, `bar` is reverted to unspecified |
| 1366 | state, and `baz` is unset. |
| 1367 | |
| 1368 | As the result, the attributes assignment to `t/abc` becomes: |
| 1369 | |
| 1370 | ---------------------------------------------------------------- |
| 1371 | foo set to true |
| 1372 | bar unspecified |
| 1373 | baz set to false |
| 1374 | merge set to string value "filfre" |
| 1375 | frotz unspecified |
| 1376 | ---------------------------------------------------------------- |
| 1377 | |
| 1378 | |
| 1379 | SEE ALSO |
| 1380 | -------- |
| 1381 | linkgit:git-check-attr[1]. |
| 1382 | |
| 1383 | GIT |
| 1384 | --- |
| 1385 | Part of the linkgit:git[1] suite |