| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" | |
| "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> | |
| <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> | |
| <head> | |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> | |
| <meta name="generator" content="AsciiDoc 8.2.5" /> | |
| <style type="text/css"> | |
| /* Debug borders */ | |
| p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 { | |
| /* | |
| border: 1px solid red; | |
| */ | |
| } | |
| body { | |
| margin: 1em 5% 1em 5%; | |
| } | |
| a { | |
| color: blue; | |
| text-decoration: underline; | |
| } | |
| a:visited { | |
| color: fuchsia; | |
| } | |
| em { | |
| font-style: italic; | |
| } | |
| strong { | |
| font-weight: bold; | |
| } | |
| tt { | |
| color: navy; | |
| } | |
| h1, h2, h3, h4, h5, h6 { | |
| color: #527bbd; | |
| font-family: sans-serif; | |
| margin-top: 1.2em; | |
| margin-bottom: 0.5em; | |
| line-height: 1.3; | |
| } | |
| h1, h2, h3 { | |
| border-bottom: 2px solid silver; | |
| } | |
| h2 { | |
| padding-top: 0.5em; | |
| } | |
| h3 { | |
| float: left; | |
| } | |
| h3 + * { | |
| clear: left; | |
| } | |
| div.sectionbody { | |
| font-family: serif; | |
| margin-left: 0; | |
| } | |
| hr { | |
| border: 1px solid silver; | |
| } | |
| p { | |
| margin-top: 0.5em; | |
| margin-bottom: 0.5em; | |
| } | |
| pre { | |
| padding: 0; | |
| margin: 0; | |
| } | |
| span#author { | |
| color: #527bbd; | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| font-size: 1.1em; | |
| } | |
| span#email { | |
| } | |
| span#revision { | |
| font-family: sans-serif; | |
| } | |
| div#footer { | |
| font-family: sans-serif; | |
| font-size: small; | |
| border-top: 2px solid silver; | |
| padding-top: 0.5em; | |
| margin-top: 4.0em; | |
| } | |
| div#footer-text { | |
| float: left; | |
| padding-bottom: 0.5em; | |
| } | |
| div#footer-badges { | |
| float: right; | |
| padding-bottom: 0.5em; | |
| } | |
| div#preamble, | |
| div.tableblock, div.imageblock, div.exampleblock, div.verseblock, | |
| div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock, | |
| div.admonitionblock { | |
| margin-right: 10%; | |
| margin-top: 1.5em; | |
| margin-bottom: 1.5em; | |
| } | |
| div.admonitionblock { | |
| margin-top: 2.5em; | |
| margin-bottom: 2.5em; | |
| } | |
| div.content { /* Block element content. */ | |
| padding: 0; | |
| } | |
| /* Block element titles. */ | |
| div.title, caption.title { | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| text-align: left; | |
| margin-top: 1.0em; | |
| margin-bottom: 0.5em; | |
| } | |
| div.title + * { | |
| margin-top: 0; | |
| } | |
| td div.title:first-child { | |
| margin-top: 0.0em; | |
| } | |
| div.content div.title:first-child { | |
| margin-top: 0.0em; | |
| } | |
| div.content + div.title { | |
| margin-top: 0.0em; | |
| } | |
| div.sidebarblock > div.content { | |
| background: #ffffee; | |
| border: 1px solid silver; | |
| padding: 0.5em; | |
| } | |
| div.listingblock { | |
| margin-right: 0%; | |
| } | |
| div.listingblock > div.content { | |
| border: 1px solid silver; | |
| background: #f4f4f4; | |
| padding: 0.5em; | |
| } | |
| div.quoteblock > div.content { | |
| padding-left: 2.0em; | |
| } | |
| div.attribution { | |
| text-align: right; | |
| } | |
| div.verseblock + div.attribution { | |
| text-align: left; | |
| } | |
| div.admonitionblock .icon { | |
| vertical-align: top; | |
| font-size: 1.1em; | |
| font-weight: bold; | |
| text-decoration: underline; | |
| color: #527bbd; | |
| padding-right: 0.5em; | |
| } | |
| div.admonitionblock td.content { | |
| padding-left: 0.5em; | |
| border-left: 2px solid silver; | |
| } | |
| div.exampleblock > div.content { | |
| border-left: 2px solid silver; | |
| padding: 0.5em; | |
| } | |
| div.verseblock div.content { | |
| white-space: pre; | |
| } | |
| div.imageblock div.content { padding-left: 0; } | |
| div.imageblock img { border: 1px solid silver; } | |
| span.image img { border-style: none; } | |
| dl { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| dt { | |
| margin-top: 0.5em; | |
| margin-bottom: 0; | |
| font-style: italic; | |
| } | |
| dd > *:first-child { | |
| margin-top: 0; | |
| } | |
| ul, ol { | |
| list-style-position: outside; | |
| } | |
| div.olist2 ol { | |
| list-style-type: lower-alpha; | |
| } | |
| div.tableblock > table { | |
| border: 3px solid #527bbd; | |
| } | |
| thead { | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| } | |
| tfoot { | |
| font-weight: bold; | |
| } | |
| div.hlist { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| div.hlist td { | |
| padding-bottom: 5px; | |
| } | |
| td.hlist1 { | |
| vertical-align: top; | |
| font-style: italic; | |
| padding-right: 0.8em; | |
| } | |
| td.hlist2 { | |
| vertical-align: top; | |
| } | |
| @media print { | |
| div#footer-badges { display: none; } | |
| } | |
| div#toctitle { | |
| color: #527bbd; | |
| font-family: sans-serif; | |
| font-size: 1.1em; | |
| font-weight: bold; | |
| margin-top: 1.0em; | |
| margin-bottom: 0.1em; | |
| } | |
| div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 { | |
| margin-top: 0; | |
| margin-bottom: 0; | |
| } | |
| div.toclevel2 { | |
| margin-left: 2em; | |
| font-size: 0.9em; | |
| } | |
| div.toclevel3 { | |
| margin-left: 4em; | |
| font-size: 0.9em; | |
| } | |
| div.toclevel4 { | |
| margin-left: 6em; | |
| font-size: 0.9em; | |
| } | |
| include1::./stylesheets/xhtml11-manpage.css[] | |
| /* Workarounds for IE6's broken and incomplete CSS2. */ | |
| div.sidebar-content { | |
| background: #ffffee; | |
| border: 1px solid silver; | |
| padding: 0.5em; | |
| } | |
| div.sidebar-title, div.image-title { | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| margin-top: 0.0em; | |
| margin-bottom: 0.5em; | |
| } | |
| div.listingblock div.content { | |
| border: 1px solid silver; | |
| background: #f4f4f4; | |
| padding: 0.5em; | |
| } | |
| div.quoteblock-content { | |
| padding-left: 2.0em; | |
| } | |
| div.exampleblock-content { | |
| border-left: 2px solid silver; | |
| padding-left: 0.5em; | |
| } | |
| /* IE6 sets dynamically generated links as visited. */ | |
| div#toc a:visited { color: blue; } | |
| </style> | |
| <title>gitattributes(5)</title> | |
| </head> | |
| <body> | |
| <div id="header"> | |
| <h1> | |
| gitattributes(5) Manual Page | |
| </h1> | |
| <h2>NAME</h2> | |
| <div class="sectionbody"> | |
| <p>gitattributes - | |
| defining attributes per path | |
| </p> | |
| </div> | |
| </div> | |
| <h2>SYNOPSIS</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>$GIT_DIR/info/attributes, .gitattributes</p></div> | |
| </div> | |
| <h2 id="_description">DESCRIPTION</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>A <tt>gitattributes</tt> file is a simple text file that gives | |
| <tt>attributes</tt> to pathnames.</p></div> | |
| <div class="para"><p>Each line in <tt>gitattributes</tt> file is of form:</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>glob attr1 attr2 ...</tt></pre> | |
| </div></div> | |
| <div class="para"><p>That is, a glob pattern followed by an attributes list, | |
| separated by whitespaces. When the glob pattern matches the | |
| path in question, the attributes listed on the line are given to | |
| the path.</p></div> | |
| <div class="para"><p>Each attribute can be in one of these states for a given path:</p></div> | |
| <div class="vlist"><dl> | |
| <dt> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| The path has the attribute with special value "true"; | |
| this is specified by listing only the name of the | |
| attribute in the attribute list. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unset | |
| </dt> | |
| <dd> | |
| <p> | |
| The path has the attribute with special value "false"; | |
| this is specified by listing the name of the attribute | |
| prefixed with a dash <tt>-</tt> in the attribute list. | |
| </p> | |
| </dd> | |
| <dt> | |
| Set to a value | |
| </dt> | |
| <dd> | |
| <p> | |
| The path has the attribute with specified string value; | |
| this is specified by listing the name of the attribute | |
| followed by an equal sign <tt>=</tt> and its value in the | |
| attribute list. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| No glob pattern matches the path, and nothing says if | |
| the path has or does not have the attribute, the | |
| attribute for the path is said to be Unspecified. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <div class="para"><p>When more than one glob pattern matches the path, a later line | |
| overrides an earlier line. This overriding is done per | |
| attribute.</p></div> | |
| <div class="para"><p>When deciding what attributes are assigned to a path, git | |
| consults <tt>$GIT_DIR/info/attributes</tt> file (which has the highest | |
| precedence), <tt>.gitattributes</tt> file in the same directory as the | |
| path in question, and its parent directories (the further the | |
| directory that contains <tt>.gitattributes</tt> is from the path in | |
| question, the lower its precedence).</p></div> | |
| <div class="para"><p>If you wish to affect only a single repository (i.e., to assign | |
| attributes to files that are particular to one user's workflow), then | |
| attributes should be placed in the <tt>$GIT_DIR/info/attributes</tt> file. | |
| Attributes which should be version-controlled and distributed to other | |
| repositories (i.e., attributes of interest to all users) should go into | |
| <tt>.gitattributes</tt> files.</p></div> | |
| <div class="para"><p>Sometimes you would need to override an setting of an attribute | |
| for a path to <tt>unspecified</tt> state. This can be done by listing | |
| the name of the attribute prefixed with an exclamation point <tt>!</tt>.</p></div> | |
| </div> | |
| <h2 id="_effects">EFFECTS</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>Certain operations by git can be influenced by assigning | |
| particular attributes to a path. Currently, the following | |
| operations are attributes-aware.</p></div> | |
| <h3 id="_checking_out_and_checking_in">Checking-out and checking-in</h3><div style="clear:left"></div> | |
| <div class="para"><p>These attributes affect how the contents stored in the | |
| repository are copied to the working tree files when commands | |
| such as <em>git-checkout</em> and <em>git-merge</em> run. They also affect how | |
| git stores the contents you prepare in the working tree in the | |
| repository upon <em>git-add</em> and <em>git-commit</em>.</p></div> | |
| <h4 id="_tt_crlf_tt"><tt>crlf</tt></h4> | |
| <div class="para"><p>This attribute controls the line-ending convention.</p></div> | |
| <div class="vlist"><dl> | |
| <dt> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| Setting the <tt>crlf</tt> attribute on a path is meant to mark | |
| the path as a "text" file. <em>core.autocrlf</em> conversion | |
| takes place without guessing the content type by | |
| inspection. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unset | |
| </dt> | |
| <dd> | |
| <p> | |
| Unsetting the <tt>crlf</tt> attribute on a path tells git not to | |
| attempt any end-of-line conversion upon checkin or checkout. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| Unspecified <tt>crlf</tt> attribute tells git to apply the | |
| <tt>core.autocrlf</tt> conversion when the file content looks | |
| like text. | |
| </p> | |
| </dd> | |
| <dt> | |
| Set to string value "input" | |
| </dt> | |
| <dd> | |
| <p> | |
| This is similar to setting the attribute to <tt>true</tt>, but | |
| also forces git to act as if <tt>core.autocrlf</tt> is set to | |
| <tt>input</tt> for the path. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <div class="para"><p>Any other value set to <tt>crlf</tt> attribute is ignored and git acts | |
| as if the attribute is left unspecified.</p></div> | |
| <h4 id="_the_tt_core_autocrlf_tt_conversion">The <tt>core.autocrlf</tt> conversion</h4> | |
| <div class="para"><p>If the configuration variable <tt>core.autocrlf</tt> is false, no | |
| conversion is done.</p></div> | |
| <div class="para"><p>When <tt>core.autocrlf</tt> is true, it means that the platform wants | |
| CRLF line endings for files in the working tree, and you want to | |
| convert them back to the normal LF line endings when checking | |
| in to the repository.</p></div> | |
| <div class="para"><p>When <tt>core.autocrlf</tt> is set to "input", line endings are | |
| converted to LF upon checkin, but there is no conversion done | |
| upon checkout.</p></div> | |
| <div class="para"><p>If <tt>core.safecrlf</tt> is set to "true" or "warn", git verifies if | |
| the conversion is reversible for the current setting of | |
| <tt>core.autocrlf</tt>. For "true", git rejects irreversible | |
| conversions; for "warn", git only prints a warning but accepts | |
| an irreversible conversion. The safety triggers to prevent such | |
| a conversion done to the files in the work tree, but there are a | |
| few exceptions. Even though…</p></div> | |
| <div class="ilist"><ul> | |
| <li> | |
| <p> | |
| <em>git-add</em> itself does not touch the files in the work tree, the | |
| next checkout would, so the safety triggers; | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <em>git-apply</em> to update a text file with a patch does touch the files | |
| in the work tree, but the operation is about text files and CRLF | |
| conversion is about fixing the line ending inconsistencies, so the | |
| safety does not trigger; | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <em>git-diff</em> itself does not touch the files in the work tree, it is | |
| often run to inspect the changes you intend to next <em>git-add</em>. To | |
| catch potential problems early, safety triggers. | |
| </p> | |
| </li> | |
| </ul></div> | |
| <h4 id="_tt_ident_tt"><tt>ident</tt></h4> | |
| <div class="para"><p>When the attribute <tt>ident</tt> is set for a path, git replaces | |
| <tt>$Id$</tt> in the blob object with <tt>$Id:</tt>, followed by the | |
| 40-character hexadecimal blob object name, followed by a dollar | |
| sign <tt>$</tt> upon checkout. Any byte sequence that begins with | |
| <tt>$Id:</tt> and ends with <tt>$</tt> in the worktree file is replaced | |
| with <tt>$Id$</tt> upon check-in.</p></div> | |
| <h4 id="_tt_filter_tt"><tt>filter</tt></h4> | |
| <div class="para"><p>A <tt>filter</tt> attribute can be set to a string value that names a | |
| filter driver specified in the configuration.</p></div> | |
| <div class="para"><p>A filter driver consists of a <tt>clean</tt> command and a <tt>smudge</tt> | |
| command, either of which can be left unspecified. Upon | |
| checkout, when the <tt>smudge</tt> command is specified, the command is | |
| fed the blob object from its standard input, and its standard | |
| output is used to update the worktree file. Similarly, the | |
| <tt>clean</tt> command is used to convert the contents of worktree file | |
| upon checkin.</p></div> | |
| <div class="para"><p>A missing filter driver definition in the config is not an error | |
| but makes the filter a no-op passthru.</p></div> | |
| <div class="para"><p>The content filtering is done to massage the content into a | |
| shape that is more convenient for the platform, filesystem, and | |
| the user to use. The key phrase here is "more convenient" and not | |
| "turning something unusable into usable". In other words, the | |
| intent is that if someone unsets the filter driver definition, | |
| or does not have the appropriate filter program, the project | |
| should still be usable.</p></div> | |
| <h4 id="_interaction_between_checkin_checkout_attributes">Interaction between checkin/checkout attributes</h4> | |
| <div class="para"><p>In the check-in codepath, the worktree file is first converted | |
| with <tt>filter</tt> driver (if specified and corresponding driver | |
| defined), then the result is processed with <tt>ident</tt> (if | |
| specified), and then finally with <tt>crlf</tt> (again, if specified | |
| and applicable).</p></div> | |
| <div class="para"><p>In the check-out codepath, the blob content is first converted | |
| with <tt>crlf</tt>, and then <tt>ident</tt> and fed to <tt>filter</tt>.</p></div> | |
| <h3 id="_generating_diff_text">Generating diff text</h3><div style="clear:left"></div> | |
| <h4 id="_tt_diff_tt"><tt>diff</tt></h4> | |
| <div class="para"><p>The attribute <tt>diff</tt> affects how <em>git</em> generates diffs for particular | |
| files. It can tell git whether to generate a textual patch for the path | |
| or to treat the path as a binary file. It can also affect what line is | |
| shown on the hunk header <tt>@@ -k,l +n,m @@</tt> line, tell git to use an | |
| external command to generate the diff, or ask git to convert binary | |
| files to a text format before generating the diff.</p></div> | |
| <div class="vlist"><dl> | |
| <dt> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| A path to which the <tt>diff</tt> attribute is set is treated | |
| as text, even when they contain byte values that | |
| normally never appear in text files, such as NUL. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unset | |
| </dt> | |
| <dd> | |
| <p> | |
| A path to which the <tt>diff</tt> attribute is unset will | |
| generate <tt>Binary files differ</tt> (or a binary patch, if | |
| binary patches are enabled). | |
| </p> | |
| </dd> | |
| <dt> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| A path to which the <tt>diff</tt> attribute is unspecified | |
| first gets its contents inspected, and if it looks like | |
| text, it is treated as text. Otherwise it would | |
| generate <tt>Binary files differ</tt>. | |
| </p> | |
| </dd> | |
| <dt> | |
| String | |
| </dt> | |
| <dd> | |
| <p> | |
| Diff is shown using the specified diff driver. Each driver may | |
| specify one or more options, as described in the following | |
| section. The options for the diff driver "foo" are defined | |
| by the configuration variables in the "diff.foo" section of the | |
| git config file. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <h4 id="_defining_an_external_diff_driver">Defining an external diff driver</h4> | |
| <div class="para"><p>The definition of a diff driver is done in <tt>gitconfig</tt>, not | |
| <tt>gitattributes</tt> file, so strictly speaking this manual page is a | |
| wrong place to talk about it. However…</p></div> | |
| <div class="para"><p>To define an external diff driver <tt>jcdiff</tt>, add a section to your | |
| <tt>$GIT_DIR/config</tt> file (or <tt>$HOME/.gitconfig</tt> file) like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>[diff "jcdiff"] | |
| command = j-c-diff</tt></pre> | |
| </div></div> | |
| <div class="para"><p>When git needs to show you a diff for the path with <tt>diff</tt> | |
| attribute set to <tt>jcdiff</tt>, it calls the command you specified | |
| with the above configuration, i.e. <tt>j-c-diff</tt>, with 7 | |
| parameters, just like <tt>GIT_EXTERNAL_DIFF</tt> program is called. | |
| See <a href="git.html">git(1)</a> for details.</p></div> | |
| <h4 id="_defining_a_custom_hunk_header">Defining a custom hunk-header</h4> | |
| <div class="para"><p>Each group of changes (called a "hunk") in the textual diff output | |
| is prefixed with a line of the form:</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>@@ -k,l +n,m @@ TEXT</tt></pre> | |
| </div></div> | |
| <div class="para"><p>This is called a <em>hunk header</em>. The "TEXT" portion is by default a line | |
| that begins with an alphabet, an underscore or a dollar sign; this | |
| matches what GNU <em>diff -p</em> output uses. This default selection however | |
| is not suited for some contents, and you can use a customized pattern | |
| to make a selection.</p></div> | |
| <div class="para"><p>First, in .gitattributes, you would assign the <tt>diff</tt> attribute | |
| for paths.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>*.tex diff=tex</tt></pre> | |
| </div></div> | |
| <div class="para"><p>Then, you would define a "diff.tex.xfuncname" configuration to | |
| specify a regular expression that matches a line that you would | |
| want to appear as the hunk header "TEXT", like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>[diff "tex"] | |
| xfuncname = "^(\\\\(sub)*section\\{.*)$"</tt></pre> | |
| </div></div> | |
| <div class="para"><p>Note. A single level of backslashes are eaten by the | |
| configuration file parser, so you would need to double the | |
| backslashes; the pattern above picks a line that begins with a | |
| backslash, and zero or more occurrences of <tt>sub</tt> followed by | |
| <tt>section</tt> followed by open brace, to the end of line.</p></div> | |
| <div class="para"><p>There are a few built-in patterns to make this easier, and <tt>tex</tt> | |
| is one of them, so you do not have to write the above in your | |
| configuration file (you still need to enable this with the | |
| attribute mechanism, via <tt>.gitattributes</tt>). The following built in | |
| patterns are available:</p></div> | |
| <div class="ilist"><ul> | |
| <li> | |
| <p> | |
| <tt>bibtex</tt> suitable for files with BibTeX coded references. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>html</tt> suitable for HTML/XHTML documents. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>java</tt> suitable for source code in the Java language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>objc</tt> suitable for source code in the Objective-C language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>pascal</tt> suitable for source code in the Pascal/Delphi language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>php</tt> suitable for source code in the PHP language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>python</tt> suitable for source code in the Python language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>ruby</tt> suitable for source code in the Ruby language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>tex</tt> suitable for source code for LaTeX documents. | |
| </p> | |
| </li> | |
| </ul></div> | |
| <h4 id="_performing_text_diffs_of_binary_files">Performing text diffs of binary files</h4> | |
| <div class="para"><p>Sometimes it is desirable to see the diff of a text-converted | |
| version of some binary files. For example, a word processor | |
| document can be converted to an ASCII text representation, and | |
| the diff of the text shown. Even though this conversion loses | |
| some information, the resulting diff is useful for human | |
| viewing (but cannot be applied directly).</p></div> | |
| <div class="para"><p>The <tt>textconv</tt> config option is used to define a program for | |
| performing such a conversion. The program should take a single | |
| argument, the name of a file to convert, and produce the | |
| resulting text on stdout.</p></div> | |
| <div class="para"><p>For example, to show the diff of the exif information of a | |
| file instead of the binary information (assuming you have the | |
| exif tool installed):</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>[diff "jpg"] | |
| textconv = exif</tt></pre> | |
| </div></div> | |
| <div class="admonitionblock"> | |
| <table><tr> | |
| <td class="icon"> | |
| <div class="title">Note</div> | |
| </td> | |
| <td class="content">The text conversion is generally a one-way conversion; | |
| in this example, we lose the actual image contents and focus | |
| just on the text data. This means that diffs generated by | |
| textconv are _not_ suitable for applying. For this reason, | |
| only <tt>git diff</tt> and the <tt>git log</tt> family of commands (i.e., | |
| log, whatchanged, show) will perform text conversion. <tt>git | |
| format-patch</tt> will never generate this output. If you want to | |
| send somebody a text-converted diff of a binary file (e.g., | |
| because it quickly conveys the changes you have made), you | |
| should generate it separately and send it as a comment _in | |
| addition to_ the usual binary diff that you might send.</td> | |
| </tr></table> | |
| </div> | |
| <h3 id="_performing_a_three_way_merge">Performing a three-way merge</h3><div style="clear:left"></div> | |
| <h4 id="_tt_merge_tt"><tt>merge</tt></h4> | |
| <div class="para"><p>The attribute <tt>merge</tt> affects how three versions of a file is | |
| merged when a file-level merge is necessary during <tt>git merge</tt>, | |
| and other programs such as <tt>git revert</tt> and <tt>git cherry-pick</tt>.</p></div> | |
| <div class="vlist"><dl> | |
| <dt> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| Built-in 3-way merge driver is used to merge the | |
| contents in a way similar to <em>merge</em> command of <tt>RCS</tt> | |
| suite. This is suitable for ordinary text files. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unset | |
| </dt> | |
| <dd> | |
| <p> | |
| Take the version from the current branch as the | |
| tentative merge result, and declare that the merge has | |
| conflicts. This is suitable for binary files that does | |
| not have a well-defined merge semantics. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| By default, this uses the same built-in 3-way merge | |
| driver as is the case the <tt>merge</tt> attribute is set. | |
| However, <tt>merge.default</tt> configuration variable can name | |
| different merge driver to be used for paths to which the | |
| <tt>merge</tt> attribute is unspecified. | |
| </p> | |
| </dd> | |
| <dt> | |
| String | |
| </dt> | |
| <dd> | |
| <p> | |
| 3-way merge is performed using the specified custom | |
| merge driver. The built-in 3-way merge driver can be | |
| explicitly specified by asking for "text" driver; the | |
| built-in "take the current branch" driver can be | |
| requested with "binary". | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <h4 id="_built_in_merge_drivers">Built-in merge drivers</h4> | |
| <div class="para"><p>There are a few built-in low-level merge drivers defined that | |
| can be asked for via the <tt>merge</tt> attribute.</p></div> | |
| <div class="vlist"><dl> | |
| <dt> | |
| text | |
| </dt> | |
| <dd> | |
| <p> | |
| Usual 3-way file level merge for text files. Conflicted | |
| regions are marked with conflict markers <tt><<<<<<<</tt>, | |
| <tt>=======</tt> and <tt>>>>>>>></tt>. The version from your branch | |
| appears before the <tt>=======</tt> marker, and the version | |
| from the merged branch appears after the <tt>=======</tt> | |
| marker. | |
| </p> | |
| </dd> | |
| <dt> | |
| binary | |
| </dt> | |
| <dd> | |
| <p> | |
| Keep the version from your branch in the work tree, but | |
| leave the path in the conflicted state for the user to | |
| sort out. | |
| </p> | |
| </dd> | |
| <dt> | |
| union | |
| </dt> | |
| <dd> | |
| <p> | |
| Run 3-way file level merge for text files, but take | |
| lines from both versions, instead of leaving conflict | |
| markers. This tends to leave the added lines in the | |
| resulting file in random order and the user should | |
| verify the result. Do not use this if you do not | |
| understand the implications. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <h4 id="_defining_a_custom_merge_driver">Defining a custom merge driver</h4> | |
| <div class="para"><p>The definition of a merge driver is done in the <tt>.git/config</tt> | |
| file, not in the <tt>gitattributes</tt> file, so strictly speaking this | |
| manual page is a wrong place to talk about it. However…</p></div> | |
| <div class="para"><p>To define a custom merge driver <tt>filfre</tt>, add a section to your | |
| <tt>$GIT_DIR/config</tt> file (or <tt>$HOME/.gitconfig</tt> file) like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>[merge "filfre"] | |
| name = feel-free merge driver | |
| driver = filfre %O %A %B | |
| recursive = binary</tt></pre> | |
| </div></div> | |
| <div class="para"><p>The <tt>merge.*.name</tt> variable gives the driver a human-readable | |
| name.</p></div> | |
| <div class="para"><p>The <tt>merge.*.driver</tt> variable's value is used to construct a | |
| command to run to merge ancestor's version (<tt>%O</tt>), current | |
| version (<tt>%A</tt>) and the other branches' version (<tt>%B</tt>). These | |
| three tokens are replaced with the names of temporary files that | |
| hold the contents of these versions when the command line is | |
| built.</p></div> | |
| <div class="para"><p>The merge driver is expected to leave the result of the merge in | |
| the file named with <tt>%A</tt> by overwriting it, and exit with zero | |
| status if it managed to merge them cleanly, or non-zero if there | |
| were conflicts.</p></div> | |
| <div class="para"><p>The <tt>merge.*.recursive</tt> variable specifies what other merge | |
| driver to use when the merge driver is called for an internal | |
| merge between common ancestors, when there are more than one. | |
| When left unspecified, the driver itself is used for both | |
| internal merge and the final merge.</p></div> | |
| <h3 id="_checking_whitespace_errors">Checking whitespace errors</h3><div style="clear:left"></div> | |
| <h4 id="_tt_whitespace_tt"><tt>whitespace</tt></h4> | |
| <div class="para"><p>The <tt>core.whitespace</tt> configuration variable allows you to define what | |
| <em>diff</em> and <em>apply</em> should consider whitespace errors for all paths in | |
| the project (See <a href="git-config.html">git-config(1)</a>). This attribute gives you finer | |
| control per path.</p></div> | |
| <div class="vlist"><dl> | |
| <dt> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| Notice all types of potential whitespace errors known to git. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unset | |
| </dt> | |
| <dd> | |
| <p> | |
| Do not notice anything as error. | |
| </p> | |
| </dd> | |
| <dt> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| Use the value of <tt>core.whitespace</tt> configuration variable to | |
| decide what to notice as error. | |
| </p> | |
| </dd> | |
| <dt> | |
| String | |
| </dt> | |
| <dd> | |
| <p> | |
| Specify a comma separate list of common whitespace problems to | |
| notice in the same format as <tt>core.whitespace</tt> configuration | |
| variable. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <h3 id="_creating_an_archive">Creating an archive</h3><div style="clear:left"></div> | |
| <h4 id="_tt_export_ignore_tt"><tt>export-ignore</tt></h4> | |
| <div class="para"><p>Files and directories with the attribute <tt>export-ignore</tt> won't be added to | |
| archive files.</p></div> | |
| <h4 id="_tt_export_subst_tt"><tt>export-subst</tt></h4> | |
| <div class="para"><p>If the attribute <tt>export-subst</tt> is set for a file then git will expand | |
| several placeholders when adding this file to an archive. The | |
| expansion depends on the availability of a commit ID, i.e., if | |
| <a href="git-archive.html">git-archive(1)</a> has been given a tree instead of a commit or a | |
| tag then no replacement will be done. The placeholders are the same | |
| as those for the option <tt>--pretty=format:</tt> of <a href="git-log.html">git-log(1)</a>, | |
| except that they need to be wrapped like this: <tt>$Format:PLACEHOLDERS$</tt> | |
| in the file. E.g. the string <tt>$Format:%H$</tt> will be replaced by the | |
| commit hash.</p></div> | |
| <h3 id="_viewing_files_in_gui_tools">Viewing files in GUI tools</h3><div style="clear:left"></div> | |
| <h4 id="_tt_encoding_tt"><tt>encoding</tt></h4> | |
| <div class="para"><p>The value of this attribute specifies the character encoding that should | |
| be used by GUI tools (e.g. <a href="gitk.html">gitk(1)</a> and <a href="git-gui.html">git-gui(1)</a>) to | |
| display the contents of the relevant file. Note that due to performance | |
| considerations <a href="gitk.html">gitk(1)</a> does not use this attribute unless you | |
| manually enable per-file encodings in its options.</p></div> | |
| <div class="para"><p>If this attribute is not set or has an invalid value, the value of the | |
| <tt>gui.encoding</tt> configuration variable is used instead | |
| (See <a href="git-config.html">git-config(1)</a>).</p></div> | |
| </div> | |
| <h2 id="_using_attribute_macros">USING ATTRIBUTE MACROS</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>You do not want any end-of-line conversions applied to, nor textual diffs | |
| produced for, any binary file you track. You would need to specify e.g.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>*.jpg -crlf -diff</tt></pre> | |
| </div></div> | |
| <div class="para"><p>but that may become cumbersome, when you have many attributes. Using | |
| attribute macros, you can specify groups of attributes set or unset at | |
| the same time. The system knows a built-in attribute macro, <tt>binary</tt>:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>*.jpg binary</tt></pre> | |
| </div></div> | |
| <div class="para"><p>which is equivalent to the above. Note that the attribute macros can only | |
| be "Set" (see the above example that sets "binary" macro as if it were an | |
| ordinary attribute --- setting it in turn unsets "crlf" and "diff").</p></div> | |
| </div> | |
| <h2 id="_defining_attribute_macros">DEFINING ATTRIBUTE MACROS</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>Custom attribute macros can be defined only in the <tt>.gitattributes</tt> file | |
| at the toplevel (i.e. not in any subdirectory). The built-in attribute | |
| macro "binary" is equivalent to:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>[attr]binary -diff -crlf</tt></pre> | |
| </div></div> | |
| </div> | |
| <h2 id="_example">EXAMPLE</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>If you have these three <tt>gitattributes</tt> file:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>(in $GIT_DIR/info/attributes) | |
| a* foo !bar -baz | |
| (in .gitattributes) | |
| abc foo bar baz | |
| (in t/.gitattributes) | |
| ab* merge=filfre | |
| abc -foo -bar | |
| *.c frotz</tt></pre> | |
| </div></div> | |
| <div class="para"><p>the attributes given to path <tt>t/abc</tt> are computed as follows:</p></div> | |
| <div class="olist"><ol> | |
| <li> | |
| <p> | |
| By examining <tt>t/.gitattributes</tt> (which is in the same | |
| directory as the path in question), git finds that the first | |
| line matches. <tt>merge</tt> attribute is set. It also finds that | |
| the second line matches, and attributes <tt>foo</tt> and <tt>bar</tt> | |
| are unset. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Then it examines <tt>.gitattributes</tt> (which is in the parent | |
| directory), and finds that the first line matches, but | |
| <tt>t/.gitattributes</tt> file already decided how <tt>merge</tt>, <tt>foo</tt> | |
| and <tt>bar</tt> attributes should be given to this path, so it | |
| leaves <tt>foo</tt> and <tt>bar</tt> unset. Attribute <tt>baz</tt> is set. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Finally it examines <tt>$GIT_DIR/info/attributes</tt>. This file | |
| is used to override the in-tree settings. The first line is | |
| a match, and <tt>foo</tt> is set, <tt>bar</tt> is reverted to unspecified | |
| state, and <tt>baz</tt> is unset. | |
| </p> | |
| </li> | |
| </ol></div> | |
| <div class="para"><p>As the result, the attributes assignment to <tt>t/abc</tt> becomes:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>foo set to true | |
| bar unspecified | |
| baz set to false | |
| merge set to string value "filfre" | |
| frotz unspecified</tt></pre> | |
| </div></div> | |
| </div> | |
| <h2 id="_git">GIT</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>Part of the <a href="git.html">git(1)</a> suite</p></div> | |
| </div> | |
| <div id="footer"> | |
| <div id="footer-text"> | |
| Last updated 2008-12-10 08:33:31 UTC | |
| </div> | |
| </div> | |
| </body> | |
| </html> |