| <!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 7.0.2" /> | |
| <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; } | |
| 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 { | |
| border-bottom: 2px solid silver; | |
| } | |
| h2 { | |
| border-bottom: 2px solid silver; | |
| padding-top: 0.5em; | |
| } | |
| 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.2em; | |
| } | |
| 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 > div.content { | |
| border: 1px solid silver; | |
| background: #f4f4f4; | |
| padding: 0.5em; | |
| } | |
| div.quoteblock > div.content { | |
| padding-left: 2.0em; | |
| } | |
| div.quoteblock .attribution { | |
| text-align: right; | |
| } | |
| 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; | |
| } | |
| ol.olist2 { | |
| list-style-type: lower-alpha; | |
| } | |
| div.tableblock > table { | |
| border-color: #527bbd; | |
| border-width: 3px; | |
| } | |
| thead { | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| } | |
| tfoot { | |
| font-weight: bold; | |
| } | |
| div.hlist { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| td.hlist1 { | |
| vertical-align: top; | |
| font-style: italic; | |
| padding-right: 0.8em; | |
| } | |
| td.hlist2 { | |
| vertical-align: top; | |
| } | |
| @media print { | |
| div#footer-badges { display: none; } | |
| } | |
| include::./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; | |
| } | |
| </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"> | |
| <p>$GIT_DIR/info/attributes, gitattributes</p> | |
| </div> | |
| <h2>DESCRIPTION</h2> | |
| <div class="sectionbody"> | |
| <p>A <tt>gitattributes</tt> file is a simple text file that gives | |
| <tt>attributes</tt> to pathnames.</p> | |
| <p>Each line in <tt>gitattributes</tt> file is of form:</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>glob attr1 attr2 ...</tt></pre> | |
| </div></div> | |
| <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> | |
| <p>Each attribute can be in one of these states for a given path:</p> | |
| <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> | |
| <p>When more than one glob pattern matches the path, a later line | |
| overrides an earlier line. This overriding is done per | |
| attribute.</p> | |
| <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> | |
| <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> | |
| <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> | |
| <h2>EFFECTS</h2> | |
| <div class="sectionbody"> | |
| <p>Certain operations by git can be influenced by assigning | |
| particular attributes to a path. Currently, the following | |
| operations are attributes-aware.</p> | |
| <h3>Checking-out and checking-in</h3> | |
| <p>These attributes affect how the contents stored in the | |
| repository are copied to the working tree files when commands | |
| such as <tt>git-checkout</tt> and <tt>git-merge</tt> run. They also affect how | |
| git stores the contents you prepare in the working tree in the | |
| repository upon <tt>git-add</tt> and <tt>git-commit</tt>.</p> | |
| <h4><tt>crlf</tt></h4> | |
| <p>This attribute controls the line-ending convention.</p> | |
| <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 is meant to | |
| mark the path as a "binary" file. The path never goes | |
| through line endings conversion upon checkin/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> | |
| <p>Any other value set to <tt>crlf</tt> attribute is ignored and git acts | |
| as if the attribute is left unspecified.</p> | |
| <h4>The <tt>core.autocrlf</tt> conversion</h4> | |
| <p>If the configuration variable <tt>core.autocrlf</tt> is false, no | |
| conversion is done.</p> | |
| <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> | |
| <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> | |
| <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> | |
| <ul> | |
| <li> | |
| <p> | |
| <tt>git-add</tt> itself does not touch the files in the work tree, the | |
| next checkout would, so the safety triggers; | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <tt>git-apply</tt> 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> | |
| <tt>git-diff</tt> itself does not touch the files in the work tree, it is | |
| often run to inspect the changes you intend to next <tt>git-add</tt>. To | |
| catch potential problems early, safety triggers. | |
| </p> | |
| </li> | |
| </ul> | |
| <h4><tt>ident</tt></h4> | |
| <p>When the attribute <tt>ident</tt> is set to a path, git replaces | |
| <tt>$Id$</tt> in the blob object with <tt>$Id:</tt>, followed by | |
| 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> | |
| <h4><tt>filter</tt></h4> | |
| <p>A <tt>filter</tt> attribute can be set to a string value that names a | |
| filter driver specified in the configuration.</p> | |
| <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> | |
| <p>A missing filter driver definition in the config is not an error | |
| but makes the filter a no-op passthru.</p> | |
| <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> | |
| <h4>Interaction between checkin/checkout attributes</h4> | |
| <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> | |
| <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> | |
| <h3>Generating diff text</h3> | |
| <p>The attribute <tt>diff</tt> affects if <tt>git-diff</tt> generates textual | |
| patch for the path or just says <tt>Binary files differ</tt>. It also | |
| can affect what line is shown on the hunk header <tt>@@ -k,l +n,m @@</tt> | |
| line.</p> | |
| <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>. | |
| </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 custom diff driver. | |
| The driver program is given its input using the same | |
| calling convention as used for GIT_EXTERNAL_DIFF | |
| program. This name is also used for custom hunk header | |
| selection. | |
| </p> | |
| </dd> | |
| </dl> | |
| <h4>Defining a custom diff driver</h4> | |
| <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> | |
| <p>To define a custom 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 class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>[diff "jcdiff"] | |
| command = j-c-diff</tt></pre> | |
| </div></div> | |
| <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> | |
| <h4>Defining a custom hunk-header</h4> | |
| <p>Each group of changes (called "hunk") in the textual diff output | |
| is prefixed with a line of the form:</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>@@ -k,l +n,m @@ TEXT</tt></pre> | |
| </div></div> | |
| <p>The text is called <em>hunk header</em>, and by default a line that | |
| begins with an alphabet, an underscore or a dollar sign is used, | |
| which matches what GNU <tt>diff -p</tt> output uses. This default | |
| selection however is not suited for some contents, and you can | |
| use customized pattern to make a selection.</p> | |
| <p>First in .gitattributes, you would assign the <tt>diff</tt> attribute | |
| for paths.</p> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>*.tex diff=tex</tt></pre> | |
| </div></div> | |
| <p>Then, you would define "diff.tex.funcname" configuration to | |
| specify a regular expression that matches a line that you would | |
| want to appear as the hunk header, like this:</p> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>[diff "tex"] | |
| funcname = "^\\(\\\\\\(sub\\)*section{.*\\)$"</tt></pre> | |
| </div></div> | |
| <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> | |
| <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>). Another built-in | |
| pattern is defined for <tt>java</tt> that defines a pattern suitable | |
| for program text in Java language.</p> | |
| <h3>Performing a three-way merge</h3> | |
| <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> | |
| <dl> | |
| <dt> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| Built-in 3-way merge driver is used to merge the | |
| contents in a way similar to <tt>merge</tt> 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> | |
| <h4>Built-in merge drivers</h4> | |
| <p>There are a few built-in low-level merge drivers defined that | |
| can be asked for via the <tt>merge</tt> attribute.</p> | |
| <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> | |
| <h4>Defining a custom merge driver</h4> | |
| <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> | |
| <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 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> | |
| <p>The <tt>merge.*.name</tt> variable gives the driver a human-readable | |
| name.</p> | |
| <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> | |
| <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> | |
| <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> | |
| <h3>Checking whitespace errors</h3> | |
| <h4><tt>whitespace</tt></h4> | |
| <p>The <tt>core.whitespace</tt> configuration variable allows you to define what | |
| <tt>diff</tt> and <tt>apply</tt> 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> | |
| <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> | |
| <h2>EXAMPLE</h2> | |
| <div class="sectionbody"> | |
| <p>If you have these three <tt>gitattributes</tt> file:</p> | |
| <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> | |
| <p>the attributes given to path <tt>t/abc</tt> are computed as follows:</p> | |
| <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> | |
| <p>As the result, the attributes assignment to <tt>t/abc</tt> becomes:</p> | |
| <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> | |
| <h3>Creating an archive</h3> | |
| <h4><tt>export-ignore</tt></h4> | |
| <p>Files and directories with the attribute <tt>export-ignore</tt> won't be added to | |
| archive files.</p> | |
| <h4><tt>export-subst</tt></h4> | |
| <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 | |
| <tt>git-archive</tt> 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> | |
| <h2>GIT</h2> | |
| <div class="sectionbody"> | |
| <p>Part of the <a href="git.html">git(1)</a> suite</p> | |
| </div> | |
| <div id="footer"> | |
| <div id="footer-text"> | |
| Last updated 02-Jul-2008 03:02:09 UTC | |
| </div> | |
| </div> | |
| </body> | |
| </html> |