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