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