1GITATTRIBUTES(5) Git Manual GITATTRIBUTES(5)
2
6 gitattributes - defining attributes per path
7
9 $GIT_DIR/info/attributes, .gitattributes
10
12 A gitattributes file is a simple text file that gives attributes to
13 pathnames.
14 Each line in gitattributes file is of form:
16 pattern attr1 attr2 ...
18 That is, a pattern followed by an attributes list, separated by
20 whitespaces. When the pattern matches the path in question, the
21 attributes listed on the line are given to the path.
22 Each attribute can be in one of these states for a given path:
24 Set
26 The path has the attribute with special value "true"; this is
27 specified by listing only the name of the attribute in the
28 attribute list.
29 Unset
31 The path has the attribute with special value "false"; this is
32 specified by listing the name of the attribute prefixed with a dash
33 - in the attribute list.
34 Set to a value
36 The path has the attribute with specified string value; this is
37 specified by listing the name of the attribute followed by an equal
38 sign = and its value in the attribute list.
39 Unspecified
41 No pattern matches the path, and nothing says if the path has or
42 does not have the attribute, the attribute for the path is said to
43 be Unspecified.
44 When more than one pattern matches the path, a later line overrides an
46 earlier line. This overriding is done per attribute. The rules how the
47 pattern matches paths are the same as in .gitignore files; see
48 gitignore(5).
49 When deciding what attributes are assigned to a path, git consults
51 $GIT_DIR/info/attributes file (which has the highest precedence),
52 .gitattributes file in the same directory as the path in question, and
53 its parent directories up to the toplevel of the work tree (the further
54 the directory that contains .gitattributes is from the path in
55 question, the lower its precedence). Finally global and system-wide
56 files are considered (they have the lowest precedence).
57 If you wish to affect only a single repository (i.e., to assign
59 attributes to files that are particular to one user’s workflow for that
60 repository), then attributes should be placed in the
61 $GIT_DIR/info/attributes file. Attributes which should be
62 version-controlled and distributed to other repositories (i.e.,
63 attributes of interest to all users) should go into .gitattributes
64 files. Attributes that should affect all repositories for a single user
65 should be placed in a file specified by the core.attributesfile
66 configuration option (see git-config(1)). Attributes for all users on a
67 system should be placed in the $(prefix)/etc/gitattributes file.
68 Sometimes you would need to override an setting of an attribute for a
70 path to unspecified state. This can be done by listing the name of the
71 attribute prefixed with an exclamation point !.
72
74 Certain operations by git can be influenced by assigning particular
75 attributes to a path. Currently, the following operations are
76 attributes-aware.
77 Checking-out and checking-in
79 These attributes affect how the contents stored in the repository are
80 copied to the working tree files when commands such as git checkout and
81 git merge run. They also affect how git stores the contents you prepare
82 in the working tree in the repository upon git add and git commit.
83 text
85 This attribute enables and controls end-of-line normalization. When
86 a text file is normalized, its line endings are converted to LF in
87 the repository. To control what line ending style is used in the
88 working directory, use the eol attribute for a single file and the
89 core.eol configuration variable for all text files.
90 Set
92 Setting the text attribute on a path enables end-of-line
93 normalization and marks the path as a text file. End-of-line
94 conversion takes place without guessing the content type.
95 Unset
97 Unsetting the text attribute on a path tells git not to attempt
98 any end-of-line conversion upon checkin or checkout.
99 Set to string value "auto"
101 When text is set to "auto", the path is marked for automatic
102 end-of-line normalization. If git decides that the content is
103 text, its line endings are normalized to LF on checkin.
104 Unspecified
106 If the text attribute is unspecified, git uses the
107 core.autocrlf configuration variable to determine if the file
108 should be converted.
109 Any other value causes git to act as if text has been left
111 unspecified.
112 eol
114 This attribute sets a specific line-ending style to be used in the
115 working directory. It enables end-of-line normalization without any
116 content checks, effectively setting the text attribute.
117 Set to string value "crlf"
119 This setting forces git to normalize line endings for this file
120 on checkin and convert them to CRLF when the file is checked
121 out.
122 Set to string value "lf"
124 This setting forces git to normalize line endings to LF on
125 checkin and prevents conversion to CRLF when the file is
126 checked out.
127 Backwards compatibility with crlf attribute
129 For backwards compatibility, the crlf attribute is interpreted as
130 follows:
131 crlf text
133 -crlf -text
134 crlf=input eol=lf
135 End-of-line conversion
138 While git normally leaves file contents alone, it can be configured
139 to normalize line endings to LF in the repository and, optionally,
140 to convert them to CRLF when files are checked out.
141 Here is an example that will make git normalize .txt, .vcproj and
143 .sh files, ensure that .vcproj files have CRLF and .sh files have
144 LF in the working directory, and prevent .jpg files from being
145 normalized regardless of their content.
146 *.txt text
148 *.vcproj eol=crlf
149 *.sh eol=lf
150 *.jpg -text
151 Other source code management systems normalize all text files in
154 their repositories, and there are two ways to enable similar
155 automatic normalization in git.
156 If you simply want to have CRLF line endings in your working
158 directory regardless of the repository you are working with, you
159 can set the config variable "core.autocrlf" without changing any
160 attributes.
161 [core]
163 autocrlf = true
164 This does not force normalization of all text files, but does
167 ensure that text files that you introduce to the repository have
168 their line endings normalized to LF when they are added, and that
169 files that are already normalized in the repository stay
170 normalized.
171 If you want to interoperate with a source code management system
173 that enforces end-of-line normalization, or you simply want all
174 text files in your repository to be normalized, you should instead
175 set the text attribute to "auto" for all files.
176 * text=auto
178 This ensures that all files that git considers to be text will have
181 normalized (LF) line endings in the repository. The core.eol
182 configuration variable controls which line endings git will use for
183 normalized files in your working directory; the default is to use
184 the native line ending for your platform, or CRLF if core.autocrlf
185 is set.
186 Note
188 When text=auto normalization is enabled in an existing
189 repository, any text files containing CRLFs should be
190 normalized. If they are not they will be normalized the next
191 time someone tries to change them, causing unfortunate
192 misattribution. From a clean working directory:
193 $ echo "* text=auto" >>.gitattributes
195 $ rm .git/index # Remove the index to force git to
196 $ git reset # re-scan the working directory
197 $ git status # Show files that will be normalized
198 $ git add -u
199 $ git add .gitattributes
200 $ git commit -m "Introduce end-of-line normalization"
201 If any files that should not be normalized show up in git status,
204 unset their text attribute before running git add -u.
205 manual.pdf -text
207 Conversely, text files that git does not detect can have
210 normalization enabled manually.
211 weirdchars.txt text
213 If core.safecrlf is set to "true" or "warn", git verifies if the
216 conversion is reversible for the current setting of core.autocrlf.
217 For "true", git rejects irreversible conversions; for "warn", git
218 only prints a warning but accepts an irreversible conversion. The
219 safety triggers to prevent such a conversion done to the files in
220 the work tree, but there are a few exceptions. Even though...
221 · git add itself does not touch the files in the work tree, the
223 next checkout would, so the safety triggers;
224 · git apply to update a text file with a patch does touch the
226 files in the work tree, but the operation is about text files
227 and CRLF conversion is about fixing the line ending
228 inconsistencies, so the safety does not trigger;
229 · git diff itself does not touch the files in the work tree, it
231 is often run to inspect the changes you intend to next git add.
232 To catch potential problems early, safety triggers.
233 ident
235 When the attribute ident is set for a path, git replaces $Id$ in
236 the blob object with $Id:, followed by the 40-character hexadecimal
237 blob object name, followed by a dollar sign $ upon checkout. Any
238 byte sequence that begins with $Id: and ends with $ in the worktree
239 file is replaced with $Id$ upon check-in.
240 filter
242 A filter attribute can be set to a string value that names a filter
243 driver specified in the configuration.
244 A filter driver consists of a clean command and a smudge command,
246 either of which can be left unspecified. Upon checkout, when the
247 smudge command is specified, the command is fed the blob object
248 from its standard input, and its standard output is used to update
249 the worktree file. Similarly, the clean command is used to convert
250 the contents of worktree file upon checkin.
251 A missing filter driver definition in the config is not an error
253 but makes the filter a no-op passthru.
254 The content filtering is done to massage the content into a shape
256 that is more convenient for the platform, filesystem, and the user
257 to use. The key phrase here is "more convenient" and not "turning
258 something unusable into usable". In other words, the intent is that
259 if someone unsets the filter driver definition, or does not have
260 the appropriate filter program, the project should still be usable.
261 For example, in .gitattributes, you would assign the filter
263 attribute for paths.
264 *.c filter=indent
266 Then you would define a "filter.indent.clean" and
269 "filter.indent.smudge" configuration in your .git/config to specify
270 a pair of commands to modify the contents of C programs when the
271 source files are checked in ("clean" is run) and checked out (no
272 change is made because the command is "cat").
273 [filter "indent"]
275 clean = indent
276 smudge = cat
277 For best results, clean should not alter its output further if it
280 is run twice ("clean→clean" should be equivalent to "clean"), and
281 multiple smudge commands should not alter clean's output
282 ("smudge→smudge→clean" should be equivalent to "clean"). See the
283 section on merging below.
284 The "indent" filter is well-behaved in this regard: it will not
286 modify input that is already correctly indented. In this case, the
287 lack of a smudge filter means that the clean filter must accept its
288 own output without modifying it.
289 Sequence "%f" on the filter command line is replaced with the name
291 of the file the filter is working on. A filter might use this in
292 keyword substitution. For example:
293 [filter "p4"]
295 clean = git-p4-filter --clean %f
296 smudge = git-p4-filter --smudge %f
297 Interaction between checkin/checkout attributes
300 In the check-in codepath, the worktree file is first converted with
301 filter driver (if specified and corresponding driver defined), then
302 the result is processed with ident (if specified), and then finally
303 with text (again, if specified and applicable).
304 In the check-out codepath, the blob content is first converted with
306 text, and then ident and fed to filter.
307 Merging branches with differing checkin/checkout attributes
309 If you have added attributes to a file that cause the canonical
310 repository format for that file to change, such as adding a
311 clean/smudge filter or text/eol/ident attributes, merging anything
312 where the attribute is not in place would normally cause merge
313 conflicts.
314 To prevent these unnecessary merge conflicts, git can be told to
316 run a virtual check-out and check-in of all three stages of a file
317 when resolving a three-way merge by setting the merge.renormalize
318 configuration variable. This prevents changes caused by check-in
319 conversion from causing spurious merge conflicts when a converted
320 file is merged with an unconverted file.
321 As long as a "smudge→clean" results in the same output as a "clean"
323 even on files that are already smudged, this strategy will
324 automatically resolve all filter-related conflicts. Filters that do
325 not act in this way may cause additional merge conflicts that must
326 be resolved manually.
327 Generating diff text
329 diff
330 The attribute diff affects how git generates diffs for particular
331 files. It can tell git whether to generate a textual patch for the
332 path or to treat the path as a binary file. It can also affect what
333 line is shown on the hunk header @@ -k,l +n,m @@ line, tell git to
334 use an external command to generate the diff, or ask git to convert
335 binary files to a text format before generating the diff.
336 Set
338 A path to which the diff attribute is set is treated as text,
339 even when they contain byte values that normally never appear
340 in text files, such as NUL.
341 Unset
343 A path to which the diff attribute is unset will generate
344 Binary files differ (or a binary patch, if binary patches are
345 enabled).
346 Unspecified
348 A path to which the diff attribute is unspecified first gets
349 its contents inspected, and if it looks like text, it is
350 treated as text. Otherwise it would generate Binary files
351 differ.
352 String
354 Diff is shown using the specified diff driver. Each driver may
355 specify one or more options, as described in the following
356 section. The options for the diff driver "foo" are defined by
357 the configuration variables in the "diff.foo" section of the
358 git config file.
359 Defining an external diff driver
361 The definition of a diff driver is done in gitconfig, not
362 gitattributes file, so strictly speaking this manual page is a
363 wrong place to talk about it. However...
364 To define an external diff driver jcdiff, add a section to your
366 $GIT_DIR/config file (or $HOME/.gitconfig file) like this:
367 [diff "jcdiff"]
369 command = j-c-diff
370 When git needs to show you a diff for the path with diff attribute
373 set to jcdiff, it calls the command you specified with the above
374 configuration, i.e. j-c-diff, with 7 parameters, just like
375 GIT_EXTERNAL_DIFF program is called. See git(1) for details.
376 Defining a custom hunk-header
378 Each group of changes (called a "hunk") in the textual diff output
379 is prefixed with a line of the form:
380 @@ -k,l +n,m @@ TEXT
382 This is called a hunk header. The "TEXT" portion is by default a
384 line that begins with an alphabet, an underscore or a dollar sign;
385 this matches what GNU diff -p output uses. This default selection
386 however is not suited for some contents, and you can use a
387 customized pattern to make a selection.
388 First, in .gitattributes, you would assign the diff attribute for
390 paths.
391 *.tex diff=tex
393 Then, you would define a "diff.tex.xfuncname" configuration to
396 specify a regular expression that matches a line that you would
397 want to appear as the hunk header "TEXT". Add a section to your
398 $GIT_DIR/config file (or $HOME/.gitconfig file) like this:
399 [diff "tex"]
401 xfuncname = "^(\\\\(sub)*section\\{.*)$"
402 Note. A single level of backslashes are eaten by the configuration
405 file parser, so you would need to double the backslashes; the
406 pattern above picks a line that begins with a backslash, and zero
407 or more occurrences of sub followed by section followed by open
408 brace, to the end of line.
409 There are a few built-in patterns to make this easier, and tex is
411 one of them, so you do not have to write the above in your
412 configuration file (you still need to enable this with the
413 attribute mechanism, via .gitattributes). The following built in
414 patterns are available:
415 · bibtex suitable for files with BibTeX coded references.
417 · cpp suitable for source code in the C and C++ languages.
419 · csharp suitable for source code in the C# language.
421 · fortran suitable for source code in the Fortran language.
423 · html suitable for HTML/XHTML documents.
425 · java suitable for source code in the Java language.
427 · objc suitable for source code in the Objective-C language.
429 · pascal suitable for source code in the Pascal/Delphi language.
431 · perl suitable for source code in the Perl language.
433 · php suitable for source code in the PHP language.
435 · python suitable for source code in the Python language.
437 · ruby suitable for source code in the Ruby language.
439 · tex suitable for source code for LaTeX documents.
441 Customizing word diff
443 You can customize the rules that git diff --word-diff uses to split
444 words in a line, by specifying an appropriate regular expression in
445 the "diff.*.wordRegex" configuration variable. For example, in TeX
446 a backslash followed by a sequence of letters forms a command, but
447 several such commands can be run together without intervening
448 whitespace. To separate them, use a regular expression in your
449 $GIT_DIR/config file (or $HOME/.gitconfig file) like this:
450 [diff "tex"]
452 wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+"
453 A built-in pattern is provided for all languages listed in the
456 previous section.
457 Performing text diffs of binary files
459 Sometimes it is desirable to see the diff of a text-converted
460 version of some binary files. For example, a word processor
461 document can be converted to an ASCII text representation, and the
462 diff of the text shown. Even though this conversion loses some
463 information, the resulting diff is useful for human viewing (but
464 cannot be applied directly).
465 The textconv config option is used to define a program for
467 performing such a conversion. The program should take a single
468 argument, the name of a file to convert, and produce the resulting
469 text on stdout.
470 For example, to show the diff of the exif information of a file
472 instead of the binary information (assuming you have the exif tool
473 installed), add the following section to your $GIT_DIR/config file
474 (or $HOME/.gitconfig file):
475 [diff "jpg"]
477 textconv = exif
478 Note
481 The text conversion is generally a one-way conversion; in this
482 example, we lose the actual image contents and focus just on
483 the text data. This means that diffs generated by textconv are
484 not suitable for applying. For this reason, only git diff and
485 the git log family of commands (i.e., log, whatchanged, show)
486 will perform text conversion. git format-patch will never
487 generate this output. If you want to send somebody a
488 text-converted diff of a binary file (e.g., because it quickly
489 conveys the changes you have made), you should generate it
490 separately and send it as a comment in addition to the usual
491 binary diff that you might send.
492 Because text conversion can be slow, especially when doing a large
494 number of them with git log -p, git provides a mechanism to cache
495 the output and use it in future diffs. To enable caching, set the
496 "cachetextconv" variable in your diff driver’s config. For example:
497 [diff "jpg"]
499 textconv = exif
500 cachetextconv = true
501 This will cache the result of running "exif" on each blob
504 indefinitely. If you change the textconv config variable for a diff
505 driver, git will automatically invalidate the cache entries and
506 re-run the textconv filter. If you want to invalidate the cache
507 manually (e.g., because your version of "exif" was updated and now
508 produces better output), you can remove the cache manually with git
509 update-ref -d refs/notes/textconv/jpg (where "jpg" is the name of
510 the diff driver, as in the example above).
511 Marking files as binary
513 Git usually guesses correctly whether a blob contains text or
514 binary data by examining the beginning of the contents. However,
515 sometimes you may want to override its decision, either because a
516 blob contains binary data later in the file, or because the
517 content, while technically composed of text characters, is opaque
518 to a human reader. For example, many postscript files contain only
519 ascii characters, but produce noisy and meaningless diffs.
520 The simplest way to mark a file as binary is to unset the diff
522 attribute in the .gitattributes file:
523 *.ps -diff
525 This will cause git to generate Binary files differ (or a binary
528 patch, if binary patches are enabled) instead of a regular diff.
529 However, one may also want to specify other diff driver attributes.
531 For example, you might want to use textconv to convert postscript
532 files to an ascii representation for human viewing, but otherwise
533 treat them as binary files. You cannot specify both -diff and
534 diff=ps attributes. The solution is to use the diff.*.binary config
535 option:
536 [diff "ps"]
538 textconv = ps2ascii
539 binary = true
540 Performing a three-way merge
543 merge
544 The attribute merge affects how three versions of a file are merged
545 when a file-level merge is necessary during git merge, and other
546 commands such as git revert and git cherry-pick.
547 Set
549 Built-in 3-way merge driver is used to merge the contents in a
550 way similar to merge command of RCS suite. This is suitable for
551 ordinary text files.
552 Unset
554 Take the version from the current branch as the tentative merge
555 result, and declare that the merge has conflicts. This is
556 suitable for binary files that do not have a well-defined merge
557 semantics.
558 Unspecified
560 By default, this uses the same built-in 3-way merge driver as
561 is the case when the merge attribute is set. However, the
562 merge.default configuration variable can name different merge
563 driver to be used with paths for which the merge attribute is
564 unspecified.
565 String
567 3-way merge is performed using the specified custom merge
568 driver. The built-in 3-way merge driver can be explicitly
569 specified by asking for "text" driver; the built-in "take the
570 current branch" driver can be requested with "binary".
571 Built-in merge drivers
573 There are a few built-in low-level merge drivers defined that can
574 be asked for via the merge attribute.
575 text
577 Usual 3-way file level merge for text files. Conflicted regions
578 are marked with conflict markers <<<<<<<, ======= and >>>>>>>.
579 The version from your branch appears before the ======= marker,
580 and the version from the merged branch appears after the
581 ======= marker.
582 binary
584 Keep the version from your branch in the work tree, but leave
585 the path in the conflicted state for the user to sort out.
586 union
588 Run 3-way file level merge for text files, but take lines from
589 both versions, instead of leaving conflict markers. This tends
590 to leave the added lines in the resulting file in random order
591 and the user should verify the result. Do not use this if you
592 do not understand the implications.
593 Defining a custom merge driver
595 The definition of a merge driver is done in the .git/config file,
596 not in the gitattributes file, so strictly speaking this manual
597 page is a wrong place to talk about it. However...
598 To define a custom merge driver filfre, add a section to your
600 $GIT_DIR/config file (or $HOME/.gitconfig file) like this:
601 [merge "filfre"]
603 name = feel-free merge driver
604 driver = filfre %O %A %B
605 recursive = binary
606 The merge.*.name variable gives the driver a human-readable name.
609 The ‘merge.*.driver` variable’s value is used to construct a
611 command to run to merge ancestor’s version (%O), current version
612 (%A) and the other branches’ version (%B). These three tokens are
613 replaced with the names of temporary files that hold the contents
614 of these versions when the command line is built. Additionally, %L
615 will be replaced with the conflict marker size (see below).
616 The merge driver is expected to leave the result of the merge in
618 the file named with %A by overwriting it, and exit with zero status
619 if it managed to merge them cleanly, or non-zero if there were
620 conflicts.
621 The merge.*.recursive variable specifies what other merge driver to
623 use when the merge driver is called for an internal merge between
624 common ancestors, when there are more than one. When left
625 unspecified, the driver itself is used for both internal merge and
626 the final merge.
627 conflict-marker-size
629 This attribute controls the length of conflict markers left in the
630 work tree file during a conflicted merge. Only setting to the value
631 to a positive integer has any meaningful effect.
632 For example, this line in .gitattributes can be used to tell the
634 merge machinery to leave much longer (instead of the usual
635 7-character-long) conflict markers when merging the file
636 Documentation/git-merge.txt results in a conflict.
637 Documentation/git-merge.txt conflict-marker-size=32
639 Checking whitespace errors
642 whitespace
643 The core.whitespace configuration variable allows you to define
644 what diff and apply should consider whitespace errors for all paths
645 in the project (See git-config(1)). This attribute gives you finer
646 control per path.
647 Set
649 Notice all types of potential whitespace errors known to git.
650 The tab width is taken from the value of the core.whitespace
651 configuration variable.
652 Unset
654 Do not notice anything as error.
655 Unspecified
657 Use the value of the core.whitespace configuration variable to
658 decide what to notice as error.
659 String
661 Specify a comma separate list of common whitespace problems to
662 notice in the same format as the core.whitespace configuration
663 variable.
664 Creating an archive
666 export-ignore
667 Files and directories with the attribute export-ignore won’t be
668 added to archive files.
669 export-subst
671 If the attribute export-subst is set for a file then git will
672 expand several placeholders when adding this file to an archive.
673 The expansion depends on the availability of a commit ID, i.e., if
674 git-archive(1) has been given a tree instead of a commit or a tag
675 then no replacement will be done. The placeholders are the same as
676 those for the option --pretty=format: of git-log(1), except that
677 they need to be wrapped like this: $Format:PLACEHOLDERS$ in the
678 file. E.g. the string $Format:%H$ will be replaced by the commit
679 hash.
680 Packing objects
682 delta
683 Delta compression will not be attempted for blobs for paths with
684 the attribute delta set to false.
685 Viewing files in GUI tools
687 encoding
688 The value of this attribute specifies the character encoding that
689 should be used by GUI tools (e.g. gitk(1) and git-gui(1)) to
690 display the contents of the relevant file. Note that due to
691 performance considerations gitk(1) does not use this attribute
692 unless you manually enable per-file encodings in its options.
693 If this attribute is not set or has an invalid value, the value of
695 the gui.encoding configuration variable is used instead (See git-
696 config(1)).
697
699 You do not want any end-of-line conversions applied to, nor textual
700 diffs produced for, any binary file you track. You would need to
701 specify e.g.
702 *.jpg -text -diff
704 but that may become cumbersome, when you have many attributes. Using
707 attribute macros, you can specify groups of attributes set or unset at
708 the same time. The system knows a built-in attribute macro, binary:
709 *.jpg binary
711 which is equivalent to the above. Note that the attribute macros can
714 only be "Set" (see the above example that sets "binary" macro as if it
715 were an ordinary attribute --- setting it in turn unsets "text" and
716 "diff").
717
719 Custom attribute macros can be defined only in the .gitattributes file
720 at the toplevel (i.e. not in any subdirectory). The built-in attribute
721 macro "binary" is equivalent to:
722 [attr]binary -diff -text
724
727 If you have these three gitattributes file:
728 (in $GIT_DIR/info/attributes)
730 a* foo !bar -baz
732 (in .gitattributes)
734 abc foo bar baz
735 (in t/.gitattributes)
737 ab* merge=filfre
738 abc -foo -bar
739 *.c frotz
740 the attributes given to path t/abc are computed as follows:
743 1. By examining t/.gitattributes (which is in the same directory as
745 the path in question), git finds that the first line matches.
746 merge attribute is set. It also finds that the second line matches,
747 and attributes foo and bar are unset.
748 2. Then it examines .gitattributes (which is in the parent directory),
750 and finds that the first line matches, but t/.gitattributes file
751 already decided how merge, foo and bar attributes should be given
752 to this path, so it leaves foo and bar unset. Attribute baz is set.
753 3. Finally it examines $GIT_DIR/info/attributes. This file is used to
755 override the in-tree settings. The first line is a match, and foo
756 is set, bar is reverted to unspecified state, and baz is unset.
757 As the result, the attributes assignment to t/abc becomes:
759 foo set to true
761 bar unspecified
762 baz set to false
763 merge set to string value "filfre"
764 frotz unspecified
765
768 Part of the git(1) suite
769Git 1.7.4.4 04/11/2011 GITATTRIBUTES(5)