| <?xml version="1.0" encoding="UTF-8"?> | |
| <!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="application/xhtml+xml; charset=UTF-8" /> | |
| <meta name="generator" content="AsciiDoc 8.6.10" /> | |
| <title>gitattributes(5)</title> | |
| <style type="text/css"> | |
| /* Shared CSS for AsciiDoc xhtml11 and html5 backends */ | |
| /* Default font. */ | |
| body { | |
| font-family: Georgia,serif; | |
| } | |
| /* Title font. */ | |
| h1, h2, h3, h4, h5, h6, | |
| div.title, caption.title, | |
| thead, p.table.header, | |
| #toctitle, | |
| #author, #revnumber, #revdate, #revremark, | |
| #footer { | |
| font-family: Arial,Helvetica,sans-serif; | |
| } | |
| body { | |
| margin: 1em 5% 1em 5%; | |
| } | |
| a { | |
| color: blue; | |
| text-decoration: underline; | |
| } | |
| a:visited { | |
| color: fuchsia; | |
| } | |
| em { | |
| font-style: italic; | |
| color: navy; | |
| } | |
| strong { | |
| font-weight: bold; | |
| color: #083194; | |
| } | |
| h1, h2, h3, h4, h5, h6 { | |
| color: #527bbd; | |
| 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; | |
| } | |
| h5 { | |
| font-size: 1.0em; | |
| } | |
| div.sectionbody { | |
| margin-left: 0; | |
| } | |
| hr { | |
| border: 1px solid silver; | |
| } | |
| p { | |
| margin-top: 0.5em; | |
| margin-bottom: 0.5em; | |
| } | |
| ul, ol, li > p { | |
| margin-top: 0; | |
| } | |
| ul > li { color: #aaa; } | |
| ul > li > * { color: black; } | |
| .monospaced, code, pre { | |
| font-family: "Courier New", Courier, monospace; | |
| font-size: inherit; | |
| color: navy; | |
| padding: 0; | |
| margin: 0; | |
| } | |
| pre { | |
| white-space: pre-wrap; | |
| } | |
| #author { | |
| color: #527bbd; | |
| font-weight: bold; | |
| font-size: 1.1em; | |
| } | |
| #email { | |
| } | |
| #revnumber, #revdate, #revremark { | |
| } | |
| #footer { | |
| font-size: small; | |
| border-top: 2px solid silver; | |
| padding-top: 0.5em; | |
| margin-top: 4.0em; | |
| } | |
| #footer-text { | |
| float: left; | |
| padding-bottom: 0.5em; | |
| } | |
| #footer-badges { | |
| float: right; | |
| padding-bottom: 0.5em; | |
| } | |
| #preamble { | |
| margin-top: 1.5em; | |
| margin-bottom: 1.5em; | |
| } | |
| div.imageblock, div.exampleblock, div.verseblock, | |
| div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock, | |
| div.admonitionblock { | |
| margin-top: 1.0em; | |
| margin-bottom: 1.5em; | |
| } | |
| div.admonitionblock { | |
| margin-top: 2.0em; | |
| margin-bottom: 2.0em; | |
| margin-right: 10%; | |
| color: #606060; | |
| } | |
| div.content { /* Block element content. */ | |
| padding: 0; | |
| } | |
| /* Block element titles. */ | |
| div.title, caption.title { | |
| color: #527bbd; | |
| 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 #dddddd; | |
| border-left: 4px solid #f0f0f0; | |
| padding: 0.5em; | |
| } | |
| div.listingblock > div.content { | |
| border: 1px solid #dddddd; | |
| border-left: 5px solid #f0f0f0; | |
| background: #f8f8f8; | |
| padding: 0.5em; | |
| } | |
| div.quoteblock, div.verseblock { | |
| padding-left: 1.0em; | |
| margin-left: 1.0em; | |
| margin-right: 10%; | |
| border-left: 5px solid #f0f0f0; | |
| color: #888; | |
| } | |
| div.quoteblock > div.attribution { | |
| padding-top: 0.5em; | |
| text-align: right; | |
| } | |
| div.verseblock > pre.content { | |
| font-family: inherit; | |
| font-size: inherit; | |
| } | |
| div.verseblock > div.attribution { | |
| padding-top: 0.75em; | |
| text-align: left; | |
| } | |
| /* DEPRECATED: Pre version 8.2.7 verse style literal block. */ | |
| 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: 3px solid #dddddd; | |
| } | |
| div.exampleblock > div.content { | |
| border-left: 3px solid #dddddd; | |
| padding-left: 0.5em; | |
| } | |
| div.imageblock div.content { padding-left: 0; } | |
| span.image img { border-style: none; vertical-align: text-bottom; } | |
| a.image:visited { color: white; } | |
| dl { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| dt { | |
| margin-top: 0.5em; | |
| margin-bottom: 0; | |
| font-style: normal; | |
| color: navy; | |
| } | |
| dd > *:first-child { | |
| margin-top: 0.1em; | |
| } | |
| ul, ol { | |
| list-style-position: outside; | |
| } | |
| ol.arabic { | |
| list-style-type: decimal; | |
| } | |
| ol.loweralpha { | |
| list-style-type: lower-alpha; | |
| } | |
| ol.upperalpha { | |
| list-style-type: upper-alpha; | |
| } | |
| ol.lowerroman { | |
| list-style-type: lower-roman; | |
| } | |
| ol.upperroman { | |
| list-style-type: upper-roman; | |
| } | |
| div.compact ul, div.compact ol, | |
| div.compact p, div.compact p, | |
| div.compact div, div.compact div { | |
| margin-top: 0.1em; | |
| margin-bottom: 0.1em; | |
| } | |
| tfoot { | |
| font-weight: bold; | |
| } | |
| td > div.verse { | |
| white-space: pre; | |
| } | |
| div.hdlist { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| div.hdlist tr { | |
| padding-bottom: 15px; | |
| } | |
| dt.hdlist1.strong, td.hdlist1.strong { | |
| font-weight: bold; | |
| } | |
| td.hdlist1 { | |
| vertical-align: top; | |
| font-style: normal; | |
| padding-right: 0.8em; | |
| color: navy; | |
| } | |
| td.hdlist2 { | |
| vertical-align: top; | |
| } | |
| div.hdlist.compact tr { | |
| margin: 0; | |
| padding-bottom: 0; | |
| } | |
| .comment { | |
| background: yellow; | |
| } | |
| .footnote, .footnoteref { | |
| font-size: 0.8em; | |
| } | |
| span.footnote, span.footnoteref { | |
| vertical-align: super; | |
| } | |
| #footnotes { | |
| margin: 20px 0 20px 0; | |
| padding: 7px 0 0 0; | |
| } | |
| #footnotes div.footnote { | |
| margin: 0 0 5px 0; | |
| } | |
| #footnotes hr { | |
| border: none; | |
| border-top: 1px solid silver; | |
| height: 1px; | |
| text-align: left; | |
| margin-left: 0; | |
| width: 20%; | |
| min-width: 100px; | |
| } | |
| div.colist td { | |
| padding-right: 0.5em; | |
| padding-bottom: 0.3em; | |
| vertical-align: top; | |
| } | |
| div.colist td img { | |
| margin-top: 0.3em; | |
| } | |
| @media print { | |
| #footer-badges { display: none; } | |
| } | |
| #toc { | |
| margin-bottom: 2.5em; | |
| } | |
| #toctitle { | |
| color: #527bbd; | |
| font-size: 1.1em; | |
| font-weight: bold; | |
| margin-top: 1.0em; | |
| margin-bottom: 0.1em; | |
| } | |
| div.toclevel0, 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; | |
| } | |
| span.aqua { color: aqua; } | |
| span.black { color: black; } | |
| span.blue { color: blue; } | |
| span.fuchsia { color: fuchsia; } | |
| span.gray { color: gray; } | |
| span.green { color: green; } | |
| span.lime { color: lime; } | |
| span.maroon { color: maroon; } | |
| span.navy { color: navy; } | |
| span.olive { color: olive; } | |
| span.purple { color: purple; } | |
| span.red { color: red; } | |
| span.silver { color: silver; } | |
| span.teal { color: teal; } | |
| span.white { color: white; } | |
| span.yellow { color: yellow; } | |
| span.aqua-background { background: aqua; } | |
| span.black-background { background: black; } | |
| span.blue-background { background: blue; } | |
| span.fuchsia-background { background: fuchsia; } | |
| span.gray-background { background: gray; } | |
| span.green-background { background: green; } | |
| span.lime-background { background: lime; } | |
| span.maroon-background { background: maroon; } | |
| span.navy-background { background: navy; } | |
| span.olive-background { background: olive; } | |
| span.purple-background { background: purple; } | |
| span.red-background { background: red; } | |
| span.silver-background { background: silver; } | |
| span.teal-background { background: teal; } | |
| span.white-background { background: white; } | |
| span.yellow-background { background: yellow; } | |
| span.big { font-size: 2em; } | |
| span.small { font-size: 0.6em; } | |
| span.underline { text-decoration: underline; } | |
| span.overline { text-decoration: overline; } | |
| span.line-through { text-decoration: line-through; } | |
| div.unbreakable { page-break-inside: avoid; } | |
| /* | |
| * xhtml11 specific | |
| * | |
| * */ | |
| div.tableblock { | |
| margin-top: 1.0em; | |
| margin-bottom: 1.5em; | |
| } | |
| div.tableblock > table { | |
| border: 3px solid #527bbd; | |
| } | |
| thead, p.table.header { | |
| font-weight: bold; | |
| color: #527bbd; | |
| } | |
| p.table { | |
| margin-top: 0; | |
| } | |
| /* Because the table frame attribute is overriden by CSS in most browsers. */ | |
| div.tableblock > table[frame="void"] { | |
| border-style: none; | |
| } | |
| div.tableblock > table[frame="hsides"] { | |
| border-left-style: none; | |
| border-right-style: none; | |
| } | |
| div.tableblock > table[frame="vsides"] { | |
| border-top-style: none; | |
| border-bottom-style: none; | |
| } | |
| /* | |
| * html5 specific | |
| * | |
| * */ | |
| table.tableblock { | |
| margin-top: 1.0em; | |
| margin-bottom: 1.5em; | |
| } | |
| thead, p.tableblock.header { | |
| font-weight: bold; | |
| color: #527bbd; | |
| } | |
| p.tableblock { | |
| margin-top: 0; | |
| } | |
| table.tableblock { | |
| border-width: 3px; | |
| border-spacing: 0px; | |
| border-style: solid; | |
| border-color: #527bbd; | |
| border-collapse: collapse; | |
| } | |
| th.tableblock, td.tableblock { | |
| border-width: 1px; | |
| padding: 4px; | |
| border-style: solid; | |
| border-color: #527bbd; | |
| } | |
| table.tableblock.frame-topbot { | |
| border-left-style: hidden; | |
| border-right-style: hidden; | |
| } | |
| table.tableblock.frame-sides { | |
| border-top-style: hidden; | |
| border-bottom-style: hidden; | |
| } | |
| table.tableblock.frame-none { | |
| border-style: hidden; | |
| } | |
| th.tableblock.halign-left, td.tableblock.halign-left { | |
| text-align: left; | |
| } | |
| th.tableblock.halign-center, td.tableblock.halign-center { | |
| text-align: center; | |
| } | |
| th.tableblock.halign-right, td.tableblock.halign-right { | |
| text-align: right; | |
| } | |
| th.tableblock.valign-top, td.tableblock.valign-top { | |
| vertical-align: top; | |
| } | |
| th.tableblock.valign-middle, td.tableblock.valign-middle { | |
| vertical-align: middle; | |
| } | |
| th.tableblock.valign-bottom, td.tableblock.valign-bottom { | |
| vertical-align: bottom; | |
| } | |
| /* | |
| * manpage specific | |
| * | |
| * */ | |
| body.manpage h1 { | |
| padding-top: 0.5em; | |
| padding-bottom: 0.5em; | |
| border-top: 2px solid silver; | |
| border-bottom: 2px solid silver; | |
| } | |
| body.manpage h2 { | |
| border-style: none; | |
| } | |
| body.manpage div.sectionbody { | |
| margin-left: 3em; | |
| } | |
| @media print { | |
| body.manpage div#toc { display: none; } | |
| } | |
| </style> | |
| <script type="text/javascript"> | |
| /*<+'])'); | |
| // Function that scans the DOM tree for header elements (the DOM2 | |
| // nodeIterator API would be a better technique but not supported by all | |
| // browsers). | |
| var iterate = function (el) { | |
| for (var i = el.firstChild; i != null; i = i.nextSibling) { | |
| if (i.nodeType == 1 /* Node.ELEMENT_NODE */) { | |
| var mo = re.exec(i.tagName); | |
| if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") { | |
| result[result.length] = new TocEntry(i, getText(i), mo[1]-1); | |
| } | |
| iterate(i); | |
| } | |
| } | |
| } | |
| iterate(el); | |
| return result; | |
| } | |
| var toc = document.getElementById("toc"); | |
| if (!toc) { | |
| return; | |
| } | |
| // Delete existing TOC entries in case we're reloading the TOC. | |
| var tocEntriesToRemove = []; | |
| var i; | |
| for (i = 0; i < toc.childNodes.length; i++) { | |
| var entry = toc.childNodes[i]; | |
| if (entry.nodeName.toLowerCase() == 'div' | |
| && entry.getAttribute("class") | |
| && entry.getAttribute("class").match(/^toclevel/)) | |
| tocEntriesToRemove.push(entry); | |
| } | |
| for (i = 0; i < tocEntriesToRemove.length; i++) { | |
| toc.removeChild(tocEntriesToRemove[i]); | |
| } | |
| // Rebuild TOC entries. | |
| var entries = tocEntries(document.getElementById("content"), toclevels); | |
| for (var i = 0; i < entries.length; ++i) { | |
| var entry = entries[i]; | |
| if (entry.element.id == "") | |
| entry.element.id = "_toc_" + i; | |
| var a = document.createElement("a"); | |
| a.href = "#" + entry.element.id; | |
| a.appendChild(document.createTextNode(entry.text)); | |
| var div = document.createElement("div"); | |
| div.appendChild(a); | |
| div.className = "toclevel" + entry.toclevel; | |
| toc.appendChild(div); | |
| } | |
| if (entries.length == 0) | |
| toc.parentNode.removeChild(toc); | |
| }, | |
| ///////////////////////////////////////////////////////////////////// | |
| // Footnotes generator | |
| ///////////////////////////////////////////////////////////////////// | |
| /* Based on footnote generation code from: | |
| * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html | |
| */ | |
| footnotes: function () { | |
| // Delete existing footnote entries in case we're reloading the footnodes. | |
| var i; | |
| var noteholder = document.getElementById("footnotes"); | |
| if (!noteholder) { | |
| return; | |
| } | |
| var entriesToRemove = []; | |
| for (i = 0; i < noteholder.childNodes.length; i++) { | |
| var entry = noteholder.childNodes[i]; | |
| if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote") | |
| entriesToRemove.push(entry); | |
| } | |
| for (i = 0; i < entriesToRemove.length; i++) { | |
| noteholder.removeChild(entriesToRemove[i]); | |
| } | |
| // Rebuild footnote entries. | |
| var cont = document.getElementById("content"); | |
| var spans = cont.getElementsByTagName("span"); | |
| var refs = {}; | |
| var n = 0; | |
| for (i=0; i<spans.length; i++) { | |
| if (spans[i].className == "footnote") { | |
| n++; | |
| var note = spans[i].getAttribute("data-note"); | |
| if (!note) { | |
| // Use [\s\S] in place of . so multi-line matches work. | |
| // Because JavaScript has no s (dotall) regex flag. | |
| note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1]; | |
| spans[i].innerHTML = | |
| "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n + | |
| "' title='View footnote' class='footnote'>" + n + "</a>]"; | |
| spans[i].setAttribute("data-note", note); | |
| } | |
| noteholder.innerHTML += | |
| "<div class='footnote' id='_footnote_" + n + "'>" + | |
| "<a href='#_footnoteref_" + n + "' title='Return to text'>" + | |
| n + "</a>. " + note + "</div>"; | |
| var id =spans[i].getAttribute("id"); | |
| if (id != null) refs["#"+id] = n; | |
| } | |
| } | |
| if (n == 0) | |
| noteholder.parentNode.removeChild(noteholder); | |
| else { | |
| // Process footnoterefs. | |
| for (i=0; i<spans.length; i++) { | |
| if (spans[i].className == "footnoteref") { | |
| var href = spans[i].getElementsByTagName("a")[0].getAttribute("href"); | |
| href = href.match(/#.*/)[0]; // Because IE return full URL. | |
| n = refs[href]; | |
| spans[i].innerHTML = | |
| "[<a href='#_footnote_" + n + | |
| "' title='View footnote' class='footnote'>" + n + "</a>]"; | |
| } | |
| } | |
| } | |
| }, | |
| install: function(toclevels) { | |
| var timerId; | |
| function reinstall() { | |
| asciidoc.footnotes(); | |
| if (toclevels) { | |
| asciidoc.toc(toclevels); | |
| } | |
| } | |
| function reinstallAndRemoveTimer() { | |
| clearInterval(timerId); | |
| reinstall(); | |
| } | |
| timerId = setInterval(reinstall, 500); | |
| if (document.addEventListener) | |
| document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false); | |
| else | |
| window.onload = reinstallAndRemoveTimer; | |
| } | |
| } | |
| asciidoc.install(); | |
| /*]]>*/ | |
| </script> | |
| </head> | |
| <body class="manpage"> | |
| <div id="header"> | |
| <h1> | |
| gitattributes(5) Manual Page | |
| </h1> | |
| <h2>NAME</h2> | |
| <div class="sectionbody"> | |
| <p>gitattributes - | |
| Defining attributes per path | |
| </p> | |
| </div> | |
| </div> | |
| <div id="content"> | |
| <div class="sect1"> | |
| <h2 id="_synopsis">SYNOPSIS</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>$GIT_DIR/info/attributes, .gitattributes</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_description">DESCRIPTION</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>A <code>gitattributes</code> file is a simple text file that gives | |
| <code>attributes</code> to pathnames.</p></div> | |
| <div class="paragraph"><p>Each line in <code>gitattributes</code> file is of form:</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code>pattern attr1 attr2 ...</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>That is, a pattern followed by an attributes list, | |
| separated by whitespaces. Leading and trailing whitespaces are | |
| ignored. Lines that begin with <em>#</em> are ignored. Patterns | |
| that begin with a double quote are quoted in C style. | |
| When the pattern matches the path in question, the attributes | |
| listed on the line are given to the path.</p></div> | |
| <div class="paragraph"><p>Each attribute can be in one of these states for a given path:</p></div> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| 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 class="hdlist1"> | |
| 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 <code>-</code> in the attribute list. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| 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 <code>=</code> and its value in the | |
| attribute list. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| No 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="paragraph"><p>When more than one pattern matches the path, a later line | |
| overrides an earlier line. This overriding is done per | |
| attribute.</p></div> | |
| <div class="paragraph"><p>The rules by which the pattern matches paths are the same as in | |
| <code>.gitignore</code> files (see <a href="gitignore.html">gitignore(5)</a>), with a few exceptions:</p></div> | |
| <div class="ulist"><ul> | |
| <li> | |
| <p> | |
| negative patterns are forbidden | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| patterns that match a directory do not recursively match paths | |
| inside that directory (so using the trailing-slash <code>path/</code> syntax is | |
| pointless in an attributes file; use <code>path/**</code> instead) | |
| </p> | |
| </li> | |
| </ul></div> | |
| <div class="paragraph"><p>When deciding what attributes are assigned to a path, Git | |
| consults <code>$GIT_DIR/info/attributes</code> file (which has the highest | |
| precedence), <code>.gitattributes</code> file in the same directory as the | |
| path in question, and its parent directories up to the toplevel of the | |
| work tree (the further the directory that contains <code>.gitattributes</code> | |
| is from the path in question, the lower its precedence). Finally | |
| global and system-wide files are considered (they have the lowest | |
| precedence).</p></div> | |
| <div class="paragraph"><p>When the <code>.gitattributes</code> file is missing from the work tree, the | |
| path in the index is used as a fall-back. During checkout process, | |
| <code>.gitattributes</code> in the index is used and then the file in the | |
| working tree is used as a fall-back.</p></div> | |
| <div class="paragraph"><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 for that repository), then | |
| attributes should be placed in the <code>$GIT_DIR/info/attributes</code> file. | |
| Attributes which should be version-controlled and distributed to other | |
| repositories (i.e., attributes of interest to all users) should go into | |
| <code>.gitattributes</code> files. Attributes that should affect all repositories | |
| for a single user should be placed in a file specified by the | |
| <code>core.attributesFile</code> configuration option (see <a href="git-config.html">git-config(1)</a>). | |
| Its default value is $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME | |
| is either not set or empty, $HOME/.config/git/attributes is used instead. | |
| Attributes for all users on a system should be placed in the | |
| <code>$(prefix)/etc/gitattributes</code> file.</p></div> | |
| <div class="paragraph"><p>Sometimes you would need to override a setting of an attribute | |
| for a path to <code>Unspecified</code> state. This can be done by listing | |
| the name of the attribute prefixed with an exclamation point <code>!</code>.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_effects">EFFECTS</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>Certain operations by Git can be influenced by assigning | |
| particular attributes to a path. Currently, the following | |
| operations are attributes-aware.</p></div> | |
| <div class="sect2"> | |
| <h3 id="_checking_out_and_checking_in">Checking-out and checking-in</h3> | |
| <div class="paragraph"><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> | |
| <div class="sect3"> | |
| <h4 id="_code_text_code"><code>text</code></h4> | |
| <div class="paragraph"><p>This attribute enables and controls end-of-line normalization. When a | |
| text file is normalized, its line endings are converted to LF in the | |
| repository. To control what line ending style is used in the working | |
| directory, use the <code>eol</code> attribute for a single file and the | |
| <code>core.eol</code> configuration variable for all text files. | |
| Note that setting <code>core.autocrlf</code> to <code>true</code> or <code>input</code> overrides | |
| <code>core.eol</code> (see the definitions of those options in | |
| <a href="git-config.html">git-config(1)</a>).</p></div> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| Setting the <code>text</code> attribute on a path enables end-of-line | |
| normalization and marks the path as a text file. End-of-line | |
| conversion takes place without guessing the content type. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Unset | |
| </dt> | |
| <dd> | |
| <p> | |
| Unsetting the <code>text</code> attribute on a path tells Git not to | |
| attempt any end-of-line conversion upon checkin or checkout. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Set to string value "auto" | |
| </dt> | |
| <dd> | |
| <p> | |
| When <code>text</code> is set to "auto", the path is marked for automatic | |
| end-of-line conversion. If Git decides that the content is | |
| text, its line endings are converted to LF on checkin. | |
| When the file has been committed with CRLF, no conversion is done. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| If the <code>text</code> attribute is unspecified, Git uses the | |
| <code>core.autocrlf</code> configuration variable to determine if the | |
| file should be converted. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <div class="paragraph"><p>Any other value causes Git to act as if <code>text</code> has been left | |
| unspecified.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_code_eol_code"><code>eol</code></h4> | |
| <div class="paragraph"><p>This attribute sets a specific line-ending style to be used in the | |
| working directory. It enables end-of-line conversion without any | |
| content checks, effectively setting the <code>text</code> attribute. Note that | |
| setting this attribute on paths which are in the index with CRLF line | |
| endings may make the paths to be considered dirty. Adding the path to | |
| the index again will normalize the line endings in the index.</p></div> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| Set to string value "crlf" | |
| </dt> | |
| <dd> | |
| <p> | |
| This setting forces Git to normalize line endings for this | |
| file on checkin and convert them to CRLF when the file is | |
| checked out. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Set to string value "lf" | |
| </dt> | |
| <dd> | |
| <p> | |
| This setting forces Git to normalize line endings to LF on | |
| checkin and prevents conversion to CRLF when the file is | |
| checked out. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_backwards_compatibility_with_code_crlf_code_attribute">Backwards compatibility with <code>crlf</code> attribute</h4> | |
| <div class="paragraph"><p>For backwards compatibility, the <code>crlf</code> attribute is interpreted as | |
| follows:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>crlf text | |
| -crlf -text | |
| crlf=input eol=lf</code></pre> | |
| </div></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_end_of_line_conversion">End-of-line conversion</h4> | |
| <div class="paragraph"><p>While Git normally leaves file contents alone, it can be configured to | |
| normalize line endings to LF in the repository and, optionally, to | |
| convert them to CRLF when files are checked out.</p></div> | |
| <div class="paragraph"><p>If you simply want to have CRLF line endings in your working directory | |
| regardless of the repository you are working with, you can set the | |
| config variable "core.autocrlf" without using any attributes.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[core] | |
| autocrlf = true</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>This does not force normalization of text files, but does ensure | |
| that text files that you introduce to the repository have their line | |
| endings normalized to LF when they are added, and that files that are | |
| already normalized in the repository stay normalized.</p></div> | |
| <div class="paragraph"><p>If you want to ensure that text files that any contributor introduces to | |
| the repository have their line endings normalized, you can set the | |
| <code>text</code> attribute to "auto" for <em>all</em> files.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>* text=auto</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>The attributes allow a fine-grained control, how the line endings | |
| are converted. | |
| Here is an example that will make Git normalize .txt, .vcproj and .sh | |
| files, ensure that .vcproj files have CRLF and .sh files have LF in | |
| the working directory, and prevent .jpg files from being normalized | |
| regardless of their content.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>* text=auto | |
| *.txt text | |
| *.vcproj text eol=crlf | |
| *.sh text eol=lf | |
| *.jpg -text</code></pre> | |
| </div></div> | |
| <div class="admonitionblock"> | |
| <table><tr> | |
| <td class="icon"> | |
| <div class="title">Note</div> | |
| </td> | |
| <td class="content">When <code>text=auto</code> conversion is enabled in a cross-platform | |
| project using push and pull to a central repository the text files | |
| containing CRLFs should be normalized.</td> | |
| </tr></table> | |
| </div> | |
| <div class="paragraph"><p>From a clean working directory:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>$ echo "* text=auto" >.gitattributes | |
| $ git add --renormalize . | |
| $ git status # Show files that will be normalized | |
| $ git commit -m "Introduce end-of-line normalization"</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>If any files that should not be normalized show up in <em>git status</em>, | |
| unset their <code>text</code> attribute before running <em>git add -u</em>.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>manual.pdf -text</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>Conversely, text files that Git does not detect can have normalization | |
| enabled manually.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>weirdchars.txt text</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>If <code>core.safecrlf</code> is set to "true" or "warn", Git verifies if | |
| the conversion is reversible for the current setting of | |
| <code>core.autocrlf</code>. 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="ulist"><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> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_code_working_tree_encoding_code"><code>working-tree-encoding</code></h4> | |
| <div class="paragraph"><p>Git recognizes files encoded in ASCII or one of its supersets (e.g. | |
| UTF-8, ISO-8859-1, …) as text files. Files encoded in certain other | |
| encodings (e.g. UTF-16) are interpreted as binary and consequently | |
| built-in Git text processing tools (e.g. <em>git diff</em>) as well as most Git | |
| web front ends do not visualize the contents of these files by default.</p></div> | |
| <div class="paragraph"><p>In these cases you can tell Git the encoding of a file in the working | |
| directory with the <code>working-tree-encoding</code> attribute. If a file with this | |
| attribute is added to Git, then Git reencodes the content from the | |
| specified encoding to UTF-8. Finally, Git stores the UTF-8 encoded | |
| content in its internal data structure (called "the index"). On checkout | |
| the content is reencoded back to the specified encoding.</p></div> | |
| <div class="paragraph"><p>Please note that using the <code>working-tree-encoding</code> attribute may have a | |
| number of pitfalls:</p></div> | |
| <div class="ulist"><ul> | |
| <li> | |
| <p> | |
| Alternative Git implementations (e.g. JGit or libgit2) and older Git | |
| versions (as of March 2018) do not support the <code>working-tree-encoding</code> | |
| attribute. If you decide to use the <code>working-tree-encoding</code> attribute | |
| in your repository, then it is strongly recommended to ensure that all | |
| clients working with the repository support it. | |
| </p> | |
| <div class="paragraph"><p>For example, Microsoft Visual Studio resources files (<code>*.rc</code>) or | |
| PowerShell script files (<code>*.ps1</code>) are sometimes encoded in UTF-16. | |
| If you declare <code>*.ps1</code> as files as UTF-16 and you add <code>foo.ps1</code> with | |
| a <code>working-tree-encoding</code> enabled Git client, then <code>foo.ps1</code> will be | |
| stored as UTF-8 internally. A client without <code>working-tree-encoding</code> | |
| support will checkout <code>foo.ps1</code> as UTF-8 encoded file. This will | |
| typically cause trouble for the users of this file.</p></div> | |
| <div class="paragraph"><p>If a Git client, that does not support the <code>working-tree-encoding</code> | |
| attribute, adds a new file <code>bar.ps1</code>, then <code>bar.ps1</code> will be | |
| stored "as-is" internally (in this example probably as UTF-16). | |
| A client with <code>working-tree-encoding</code> support will interpret the | |
| internal contents as UTF-8 and try to convert it to UTF-16 on checkout. | |
| That operation will fail and cause an error.</p></div> | |
| </li> | |
| <li> | |
| <p> | |
| Reencoding content to non-UTF encodings can cause errors as the | |
| conversion might not be UTF-8 round trip safe. If you suspect your | |
| encoding to not be round trip safe, then add it to | |
| <code>core.checkRoundtripEncoding</code> to make Git check the round trip | |
| encoding (see <a href="git-config.html">git-config(1)</a>). SHIFT-JIS (Japanese character | |
| set) is known to have round trip issues with UTF-8 and is checked by | |
| default. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Reencoding content requires resources that might slow down certain | |
| Git operations (e.g <em>git checkout</em> or <em>git add</em>). | |
| </p> | |
| </li> | |
| </ul></div> | |
| <div class="paragraph"><p>Use the <code>working-tree-encoding</code> attribute only if you cannot store a file | |
| in UTF-8 encoding and if you want Git to be able to process the content | |
| as text.</p></div> | |
| <div class="paragraph"><p>As an example, use the following attributes if your <em>*.ps1</em> files are | |
| UTF-16 encoded with byte order mark (BOM) and you want Git to perform | |
| automatic line ending conversion based on your platform.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>*.ps1 text working-tree-encoding=UTF-16</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>Use the following attributes if your <em>*.ps1</em> files are UTF-16 little | |
| endian encoded without BOM and you want Git to use Windows line endings | |
| in the working directory (use <code>UTF-16-LE-BOM</code> instead of <code>UTF-16LE</code> if | |
| you want UTF-16 little endian with BOM). | |
| Please note, it is highly recommended to | |
| explicitly define the line endings with <code>eol</code> if the <code>working-tree-encoding</code> | |
| attribute is used to avoid ambiguity.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>*.ps1 text working-tree-encoding=UTF-16LE eol=CRLF</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>You can get a list of all available encodings on your platform with the | |
| following command:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>iconv --list</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>If you do not know the encoding of a file, then you can use the <code>file</code> | |
| command to guess the encoding:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>file foo.ps1</code></pre> | |
| </div></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_code_ident_code"><code>ident</code></h4> | |
| <div class="paragraph"><p>When the attribute <code>ident</code> is set for a path, Git replaces | |
| <code>$Id$</code> in the blob object with <code>$Id:</code>, followed by the | |
| 40-character hexadecimal blob object name, followed by a dollar | |
| sign <code>$</code> upon checkout. Any byte sequence that begins with | |
| <code>$Id:</code> and ends with <code>$</code> in the worktree file is replaced | |
| with <code>$Id$</code> upon check-in.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_code_filter_code"><code>filter</code></h4> | |
| <div class="paragraph"><p>A <code>filter</code> attribute can be set to a string value that names a | |
| filter driver specified in the configuration.</p></div> | |
| <div class="paragraph"><p>A filter driver consists of a <code>clean</code> command and a <code>smudge</code> | |
| command, either of which can be left unspecified. Upon | |
| checkout, when the <code>smudge</code> 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 | |
| <code>clean</code> command is used to convert the contents of worktree file | |
| upon checkin. By default these commands process only a single | |
| blob and terminate. If a long running <code>process</code> filter is used | |
| in place of <code>clean</code> and/or <code>smudge</code> filters, then Git can process | |
| all blobs with a single filter command invocation for the entire | |
| life of a single Git command, for example <code>git add --all</code>. If a | |
| long running <code>process</code> filter is configured then it always takes | |
| precedence over a configured single blob filter. See section | |
| below for the description of the protocol used to communicate with | |
| a <code>process</code> filter.</p></div> | |
| <div class="paragraph"><p>One use of the content filtering is to massage the content into a shape | |
| that is more convenient for the platform, filesystem, and the user to use. | |
| For this mode of operation, 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> | |
| <div class="paragraph"><p>Another use of the content filtering is to store the content that cannot | |
| be directly used in the repository (e.g. a UUID that refers to the true | |
| content stored outside Git, or an encrypted content) and turn it into a | |
| usable form upon checkout (e.g. download the external content, or decrypt | |
| the encrypted content).</p></div> | |
| <div class="paragraph"><p>These two filters behave differently, and by default, a filter is taken as | |
| the former, massaging the contents into more convenient shape. A missing | |
| filter driver definition in the config, or a filter driver that exits with | |
| a non-zero status, is not an error but makes the filter a no-op passthru.</p></div> | |
| <div class="paragraph"><p>You can declare that a filter turns a content that by itself is unusable | |
| into a usable content by setting the filter.<driver>.required configuration | |
| variable to <code>true</code>.</p></div> | |
| <div class="paragraph"><p>Note: Whenever the clean filter is changed, the repo should be renormalized: | |
| $ git add --renormalize .</p></div> | |
| <div class="paragraph"><p>For example, in .gitattributes, you would assign the <code>filter</code> | |
| attribute for paths.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>*.c filter=indent</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>Then you would define a "filter.indent.clean" and "filter.indent.smudge" | |
| configuration in your .git/config to specify a pair of commands to | |
| modify the contents of C programs when the source files are checked | |
| in ("clean" is run) and checked out (no change is made because the | |
| command is "cat").</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[filter "indent"] | |
| clean = indent | |
| smudge = cat</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>For best results, <code>clean</code> should not alter its output further if it is | |
| run twice ("clean→clean" should be equivalent to "clean"), and | |
| multiple <code>smudge</code> commands should not alter <code>clean</code>'s output | |
| ("smudge→smudge→clean" should be equivalent to "clean"). See the | |
| section on merging below.</p></div> | |
| <div class="paragraph"><p>The "indent" filter is well-behaved in this regard: it will not modify | |
| input that is already correctly indented. In this case, the lack of a | |
| smudge filter means that the clean filter <em>must</em> accept its own output | |
| without modifying it.</p></div> | |
| <div class="paragraph"><p>If a filter <em>must</em> succeed in order to make the stored contents usable, | |
| you can declare that the filter is <code>required</code>, in the configuration:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[filter "crypt"] | |
| clean = openssl enc ... | |
| smudge = openssl enc -d ... | |
| required</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>Sequence "%f" on the filter command line is replaced with the name of | |
| the file the filter is working on. A filter might use this in keyword | |
| substitution. For example:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[filter "p4"] | |
| clean = git-p4-filter --clean %f | |
| smudge = git-p4-filter --smudge %f</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>Note that "%f" is the name of the path that is being worked on. Depending | |
| on the version that is being filtered, the corresponding file on disk may | |
| not exist, or may have different contents. So, smudge and clean commands | |
| should not try to access the file on disk, but only act as filters on the | |
| content provided to them on standard input.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_long_running_filter_process">Long Running Filter Process</h4> | |
| <div class="paragraph"><p>If the filter command (a string value) is defined via | |
| <code>filter.<driver>.process</code> then Git can process all blobs with a | |
| single filter invocation for the entire life of a single Git | |
| command. This is achieved by using the long-running process protocol | |
| (described in technical/long-running-process-protocol.txt).</p></div> | |
| <div class="paragraph"><p>When Git encounters the first file that needs to be cleaned or smudged, | |
| it starts the filter and performs the handshake. In the handshake, the | |
| welcome message sent by Git is "git-filter-client", only version 2 is | |
| suppported, and the supported capabilities are "clean", "smudge", and | |
| "delay".</p></div> | |
| <div class="paragraph"><p>Afterwards Git sends a list of "key=value" pairs terminated with | |
| a flush packet. The list will contain at least the filter command | |
| (based on the supported capabilities) and the pathname of the file | |
| to filter relative to the repository root. Right after the flush packet | |
| Git sends the content split in zero or more pkt-line packets and a | |
| flush packet to terminate content. Please note, that the filter | |
| must not send any response before it received the content and the | |
| final flush packet. Also note that the "value" of a "key=value" pair | |
| can contain the "=" character whereas the key would never contain | |
| that character.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git> command=smudge | |
| packet: git> pathname=path/testfile.dat | |
| packet: git> 0000 | |
| packet: git> CONTENT | |
| packet: git> 0000</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>The filter is expected to respond with a list of "key=value" pairs | |
| terminated with a flush packet. If the filter does not experience | |
| problems then the list must contain a "success" status. Right after | |
| these packets the filter is expected to send the content in zero | |
| or more pkt-line packets and a flush packet at the end. Finally, a | |
| second list of "key=value" pairs terminated with a flush packet | |
| is expected. The filter can change the status in the second list | |
| or keep the status as is with an empty list. Please note that the | |
| empty list must be terminated with a flush packet regardless.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git< status=success | |
| packet: git< 0000 | |
| packet: git< SMUDGED_CONTENT | |
| packet: git< 0000 | |
| packet: git< 0000 # empty list, keep "status=success" unchanged!</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>If the result content is empty then the filter is expected to respond | |
| with a "success" status and a flush packet to signal the empty content.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git< status=success | |
| packet: git< 0000 | |
| packet: git< 0000 # empty content! | |
| packet: git< 0000 # empty list, keep "status=success" unchanged!</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>In case the filter cannot or does not want to process the content, | |
| it is expected to respond with an "error" status.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git< status=error | |
| packet: git< 0000</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>If the filter experiences an error during processing, then it can | |
| send the status "error" after the content was (partially or | |
| completely) sent.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git< status=success | |
| packet: git< 0000 | |
| packet: git< HALF_WRITTEN_ERRONEOUS_CONTENT | |
| packet: git< 0000 | |
| packet: git< status=error | |
| packet: git< 0000</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>In case the filter cannot or does not want to process the content | |
| as well as any future content for the lifetime of the Git process, | |
| then it is expected to respond with an "abort" status at any point | |
| in the protocol.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git< status=abort | |
| packet: git< 0000</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>Git neither stops nor restarts the filter process in case the | |
| "error"/"abort" status is set. However, Git sets its exit code | |
| according to the <code>filter.<driver>.required</code> flag, mimicking the | |
| behavior of the <code>filter.<driver>.clean</code> / <code>filter.<driver>.smudge</code> | |
| mechanism.</p></div> | |
| <div class="paragraph"><p>If the filter dies during the communication or does not adhere to | |
| the protocol then Git will stop the filter process and restart it | |
| with the next file that needs to be processed. Depending on the | |
| <code>filter.<driver>.required</code> flag Git will interpret that as error.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_delay">Delay</h4> | |
| <div class="paragraph"><p>If the filter supports the "delay" capability, then Git can send the | |
| flag "can-delay" after the filter command and pathname. This flag | |
| denotes that the filter can delay filtering the current blob (e.g. to | |
| compensate network latencies) by responding with no content but with | |
| the status "delayed" and a flush packet.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git> command=smudge | |
| packet: git> pathname=path/testfile.dat | |
| packet: git> can-delay=1 | |
| packet: git> 0000 | |
| packet: git> CONTENT | |
| packet: git> 0000 | |
| packet: git< status=delayed | |
| packet: git< 0000</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>If the filter supports the "delay" capability then it must support the | |
| "list_available_blobs" command. If Git sends this command, then the | |
| filter is expected to return a list of pathnames representing blobs | |
| that have been delayed earlier and are now available. | |
| The list must be terminated with a flush packet followed | |
| by a "success" status that is also terminated with a flush packet. If | |
| no blobs for the delayed paths are available, yet, then the filter is | |
| expected to block the response until at least one blob becomes | |
| available. The filter can tell Git that it has no more delayed blobs | |
| by sending an empty list. As soon as the filter responds with an empty | |
| list, Git stops asking. All blobs that Git has not received at this | |
| point are considered missing and will result in an error.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git> command=list_available_blobs | |
| packet: git> 0000 | |
| packet: git< pathname=path/testfile.dat | |
| packet: git< pathname=path/otherfile.dat | |
| packet: git< 0000 | |
| packet: git< status=success | |
| packet: git< 0000</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>After Git received the pathnames, it will request the corresponding | |
| blobs again. These requests contain a pathname and an empty content | |
| section. The filter is expected to respond with the smudged content | |
| in the usual way as explained above.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>packet: git> command=smudge | |
| packet: git> pathname=path/testfile.dat | |
| packet: git> 0000 | |
| packet: git> 0000 # empty content! | |
| packet: git< status=success | |
| packet: git< 0000 | |
| packet: git< SMUDGED_CONTENT | |
| packet: git< 0000 | |
| packet: git< 0000 # empty list, keep "status=success" unchanged!</code></pre> | |
| </div></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_example">Example</h4> | |
| <div class="paragraph"><p>A long running filter demo implementation can be found in | |
| <code>contrib/long-running-filter/example.pl</code> located in the Git | |
| core repository. If you develop your own long running filter | |
| process then the <code>GIT_TRACE_PACKET</code> environment variables can be | |
| very helpful for debugging (see <a href="git.html">git(1)</a>).</p></div> | |
| <div class="paragraph"><p>Please note that you cannot use an existing <code>filter.<driver>.clean</code> | |
| or <code>filter.<driver>.smudge</code> command with <code>filter.<driver>.process</code> | |
| because the former two use a different inter process communication | |
| protocol than the latter one.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_interaction_between_checkin_checkout_attributes">Interaction between checkin/checkout attributes</h4> | |
| <div class="paragraph"><p>In the check-in codepath, the worktree file is first converted | |
| with <code>filter</code> driver (if specified and corresponding driver | |
| defined), then the result is processed with <code>ident</code> (if | |
| specified), and then finally with <code>text</code> (again, if specified | |
| and applicable).</p></div> | |
| <div class="paragraph"><p>In the check-out codepath, the blob content is first converted | |
| with <code>text</code>, and then <code>ident</code> and fed to <code>filter</code>.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_merging_branches_with_differing_checkin_checkout_attributes">Merging branches with differing checkin/checkout attributes</h4> | |
| <div class="paragraph"><p>If you have added attributes to a file that cause the canonical | |
| repository format for that file to change, such as adding a | |
| clean/smudge filter or text/eol/ident attributes, merging anything | |
| where the attribute is not in place would normally cause merge | |
| conflicts.</p></div> | |
| <div class="paragraph"><p>To prevent these unnecessary merge conflicts, Git can be told to run a | |
| virtual check-out and check-in of all three stages of a file when | |
| resolving a three-way merge by setting the <code>merge.renormalize</code> | |
| configuration variable. This prevents changes caused by check-in | |
| conversion from causing spurious merge conflicts when a converted file | |
| is merged with an unconverted file.</p></div> | |
| <div class="paragraph"><p>As long as a "smudge→clean" results in the same output as a "clean" | |
| even on files that are already smudged, this strategy will | |
| automatically resolve all filter-related conflicts. Filters that do | |
| not act in this way may cause additional merge conflicts that must be | |
| resolved manually.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_generating_diff_text">Generating diff text</h3> | |
| <div class="sect3"> | |
| <h4 id="_code_diff_code"><code>diff</code></h4> | |
| <div class="paragraph"><p>The attribute <code>diff</code> affects how Git 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 <code>@@ -k,l +n,m @@</code> 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="dlist"><dl> | |
| <dt class="hdlist1"> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| A path to which the <code>diff</code> 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 class="hdlist1"> | |
| Unset | |
| </dt> | |
| <dd> | |
| <p> | |
| A path to which the <code>diff</code> attribute is unset will | |
| generate <code>Binary files differ</code> (or a binary patch, if | |
| binary patches are enabled). | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| A path to which the <code>diff</code> attribute is unspecified | |
| first gets its contents inspected, and if it looks like | |
| text and is smaller than core.bigFileThreshold, it is treated | |
| as text. Otherwise it would generate <code>Binary files differ</code>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| 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> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_defining_an_external_diff_driver">Defining an external diff driver</h4> | |
| <div class="paragraph"><p>The definition of a diff driver is done in <code>gitconfig</code>, not | |
| <code>gitattributes</code> file, so strictly speaking this manual page is a | |
| wrong place to talk about it. However…</p></div> | |
| <div class="paragraph"><p>To define an external diff driver <code>jcdiff</code>, add a section to your | |
| <code>$GIT_DIR/config</code> file (or <code>$HOME/.gitconfig</code> file) like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[diff "jcdiff"] | |
| command = j-c-diff</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>When Git needs to show you a diff for the path with <code>diff</code> | |
| attribute set to <code>jcdiff</code>, it calls the command you specified | |
| with the above configuration, i.e. <code>j-c-diff</code>, with 7 | |
| parameters, just like <code>GIT_EXTERNAL_DIFF</code> program is called. | |
| See <a href="git.html">git(1)</a> for details.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_defining_a_custom_hunk_header">Defining a custom hunk-header</h4> | |
| <div class="paragraph"><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><code>@@ -k,l +n,m @@ TEXT</code></pre> | |
| </div></div> | |
| <div class="paragraph"><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="paragraph"><p>First, in .gitattributes, you would assign the <code>diff</code> attribute | |
| for paths.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>*.tex diff=tex</code></pre> | |
| </div></div> | |
| <div class="paragraph"><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". Add a section to your | |
| <code>$GIT_DIR/config</code> file (or <code>$HOME/.gitconfig</code> file) like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[diff "tex"] | |
| xfuncname = "^(\\\\(sub)*section\\{.*)$"</code></pre> | |
| </div></div> | |
| <div class="paragraph"><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 <code>sub</code> followed by | |
| <code>section</code> followed by open brace, to the end of line.</p></div> | |
| <div class="paragraph"><p>There are a few built-in patterns to make this easier, and <code>tex</code> | |
| 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 <code>.gitattributes</code>). The following built in | |
| patterns are available:</p></div> | |
| <div class="ulist"><ul> | |
| <li> | |
| <p> | |
| <code>ada</code> suitable for source code in the Ada language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>bibtex</code> suitable for files with BibTeX coded references. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>cpp</code> suitable for source code in the C and C++ languages. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>csharp</code> suitable for source code in the C# language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>css</code> suitable for cascading style sheets. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>fortran</code> suitable for source code in the Fortran language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>fountain</code> suitable for Fountain documents. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>golang</code> suitable for source code in the Go language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>html</code> suitable for HTML/XHTML documents. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>java</code> suitable for source code in the Java language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>matlab</code> suitable for source code in the MATLAB language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>objc</code> suitable for source code in the Objective-C language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>pascal</code> suitable for source code in the Pascal/Delphi language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>perl</code> suitable for source code in the Perl language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>php</code> suitable for source code in the PHP language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>python</code> suitable for source code in the Python language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>ruby</code> suitable for source code in the Ruby language. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| <code>tex</code> suitable for source code for LaTeX documents. | |
| </p> | |
| </li> | |
| </ul></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_customizing_word_diff">Customizing word diff</h4> | |
| <div class="paragraph"><p>You can customize the rules that <code>git diff --word-diff</code> uses to | |
| split words in a line, by specifying an appropriate regular expression | |
| in the "diff.*.wordRegex" configuration variable. For example, in TeX | |
| a backslash followed by a sequence of letters forms a command, but | |
| several such commands can be run together without intervening | |
| whitespace. To separate them, use a regular expression in your | |
| <code>$GIT_DIR/config</code> file (or <code>$HOME/.gitconfig</code> file) like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[diff "tex"] | |
| wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+"</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>A built-in pattern is provided for all languages listed in the | |
| previous section.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_performing_text_diffs_of_binary_files">Performing text diffs of binary files</h4> | |
| <div class="paragraph"><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="paragraph"><p>The <code>textconv</code> 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="paragraph"><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), add the following section to your | |
| <code>$GIT_DIR/config</code> file (or <code>$HOME/.gitconfig</code> file):</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[diff "jpg"] | |
| textconv = exif</code></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 <em>not</em> suitable for applying. For this reason, | |
| only <code>git diff</code> and the <code>git log</code> family of commands (i.e., | |
| log, whatchanged, show) will perform text conversion. <code>git | |
| format-patch</code> 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 <em>in | |
| addition to</em> the usual binary diff that you might send.</td> | |
| </tr></table> | |
| </div> | |
| <div class="paragraph"><p>Because text conversion can be slow, especially when doing a | |
| large number of them with <code>git log -p</code>, Git provides a mechanism | |
| to cache the output and use it in future diffs. To enable | |
| caching, set the "cachetextconv" variable in your diff driver’s | |
| config. For example:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[diff "jpg"] | |
| textconv = exif | |
| cachetextconv = true</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>This will cache the result of running "exif" on each blob | |
| indefinitely. If you change the textconv config variable for a | |
| diff driver, Git will automatically invalidate the cache entries | |
| and re-run the textconv filter. If you want to invalidate the | |
| cache manually (e.g., because your version of "exif" was updated | |
| and now produces better output), you can remove the cache | |
| manually with <code>git update-ref -d refs/notes/textconv/jpg</code> (where | |
| "jpg" is the name of the diff driver, as in the example above).</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_choosing_textconv_versus_external_diff">Choosing textconv versus external diff</h4> | |
| <div class="paragraph"><p>If you want to show differences between binary or specially-formatted | |
| blobs in your repository, you can choose to use either an external diff | |
| command, or to use textconv to convert them to a diff-able text format. | |
| Which method you choose depends on your exact situation.</p></div> | |
| <div class="paragraph"><p>The advantage of using an external diff command is flexibility. You are | |
| not bound to find line-oriented changes, nor is it necessary for the | |
| output to resemble unified diff. You are free to locate and report | |
| changes in the most appropriate way for your data format.</p></div> | |
| <div class="paragraph"><p>A textconv, by comparison, is much more limiting. You provide a | |
| transformation of the data into a line-oriented text format, and Git | |
| uses its regular diff tools to generate the output. There are several | |
| advantages to choosing this method:</p></div> | |
| <div class="olist arabic"><ol class="arabic"> | |
| <li> | |
| <p> | |
| Ease of use. It is often much simpler to write a binary to text | |
| transformation than it is to perform your own diff. In many cases, | |
| existing programs can be used as textconv filters (e.g., exif, | |
| odt2txt). | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Git diff features. By performing only the transformation step | |
| yourself, you can still utilize many of Git’s diff features, | |
| including colorization, word-diff, and combined diffs for merges. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Caching. Textconv caching can speed up repeated diffs, such as those | |
| you might trigger by running <code>git log -p</code>. | |
| </p> | |
| </li> | |
| </ol></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_marking_files_as_binary">Marking files as binary</h4> | |
| <div class="paragraph"><p>Git usually guesses correctly whether a blob contains text or binary | |
| data by examining the beginning of the contents. However, sometimes you | |
| may want to override its decision, either because a blob contains binary | |
| data later in the file, or because the content, while technically | |
| composed of text characters, is opaque to a human reader. For example, | |
| many postscript files contain only ASCII characters, but produce noisy | |
| and meaningless diffs.</p></div> | |
| <div class="paragraph"><p>The simplest way to mark a file as binary is to unset the diff | |
| attribute in the <code>.gitattributes</code> file:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>*.ps -diff</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>This will cause Git to generate <code>Binary files differ</code> (or a binary | |
| patch, if binary patches are enabled) instead of a regular diff.</p></div> | |
| <div class="paragraph"><p>However, one may also want to specify other diff driver attributes. For | |
| example, you might want to use <code>textconv</code> to convert postscript files to | |
| an ASCII representation for human viewing, but otherwise treat them as | |
| binary files. You cannot specify both <code>-diff</code> and <code>diff=ps</code> attributes. | |
| The solution is to use the <code>diff.*.binary</code> config option:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[diff "ps"] | |
| textconv = ps2ascii | |
| binary = true</code></pre> | |
| </div></div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_performing_a_three_way_merge">Performing a three-way merge</h3> | |
| <div class="sect3"> | |
| <h4 id="_code_merge_code"><code>merge</code></h4> | |
| <div class="paragraph"><p>The attribute <code>merge</code> affects how three versions of a file are | |
| merged when a file-level merge is necessary during <code>git merge</code>, | |
| and other commands such as <code>git revert</code> and <code>git cherry-pick</code>.</p></div> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| 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 <code>RCS</code> | |
| suite. This is suitable for ordinary text files. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| 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 do | |
| not have a well-defined merge semantics. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| By default, this uses the same built-in 3-way merge | |
| driver as is the case when the <code>merge</code> attribute is set. | |
| However, the <code>merge.default</code> configuration variable can name | |
| different merge driver to be used with paths for which the | |
| <code>merge</code> attribute is unspecified. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| 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> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_built_in_merge_drivers">Built-in merge drivers</h4> | |
| <div class="paragraph"><p>There are a few built-in low-level merge drivers defined that | |
| can be asked for via the <code>merge</code> attribute.</p></div> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| text | |
| </dt> | |
| <dd> | |
| <p> | |
| Usual 3-way file level merge for text files. Conflicted | |
| regions are marked with conflict markers <code><<<<<<<</code>, | |
| <code>=======</code> and <code>>>>>>>></code>. The version from your branch | |
| appears before the <code>=======</code> marker, and the version | |
| from the merged branch appears after the <code>=======</code> | |
| marker. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| 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 class="hdlist1"> | |
| 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> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_defining_a_custom_merge_driver">Defining a custom merge driver</h4> | |
| <div class="paragraph"><p>The definition of a merge driver is done in the <code>.git/config</code> | |
| file, not in the <code>gitattributes</code> file, so strictly speaking this | |
| manual page is a wrong place to talk about it. However…</p></div> | |
| <div class="paragraph"><p>To define a custom merge driver <code>filfre</code>, add a section to your | |
| <code>$GIT_DIR/config</code> file (or <code>$HOME/.gitconfig</code> file) like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[merge "filfre"] | |
| name = feel-free merge driver | |
| driver = filfre %O %A %B %L %P | |
| recursive = binary</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>The <code>merge.*.name</code> variable gives the driver a human-readable | |
| name.</p></div> | |
| <div class="paragraph"><p>The ‘merge.*.driver` variable’s value is used to construct a | |
| command to run to merge ancestor’s version (<code>%O</code>), current | |
| version (<code>%A</code>) and the other branches’ version (<code>%B</code>). These | |
| three tokens are replaced with the names of temporary files that | |
| hold the contents of these versions when the command line is | |
| built. Additionally, %L will be replaced with the conflict marker | |
| size (see below).</p></div> | |
| <div class="paragraph"><p>The merge driver is expected to leave the result of the merge in | |
| the file named with <code>%A</code> 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="paragraph"><p>The <code>merge.*.recursive</code> 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> | |
| <div class="paragraph"><p>The merge driver can learn the pathname in which the merged result | |
| will be stored via placeholder <code>%P</code>.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_code_conflict_marker_size_code"><code>conflict-marker-size</code></h4> | |
| <div class="paragraph"><p>This attribute controls the length of conflict markers left in | |
| the work tree file during a conflicted merge. Only setting to | |
| the value to a positive integer has any meaningful effect.</p></div> | |
| <div class="paragraph"><p>For example, this line in <code>.gitattributes</code> can be used to tell the merge | |
| machinery to leave much longer (instead of the usual 7-character-long) | |
| conflict markers when merging the file <code>Documentation/git-merge.txt</code> | |
| results in a conflict.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>Documentation/git-merge.txt conflict-marker-size=32</code></pre> | |
| </div></div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_checking_whitespace_errors">Checking whitespace errors</h3> | |
| <div class="sect3"> | |
| <h4 id="_code_whitespace_code"><code>whitespace</code></h4> | |
| <div class="paragraph"><p>The <code>core.whitespace</code> 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="dlist"><dl> | |
| <dt class="hdlist1"> | |
| Set | |
| </dt> | |
| <dd> | |
| <p> | |
| Notice all types of potential whitespace errors known to Git. | |
| The tab width is taken from the value of the <code>core.whitespace</code> | |
| configuration variable. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Unset | |
| </dt> | |
| <dd> | |
| <p> | |
| Do not notice anything as error. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| Unspecified | |
| </dt> | |
| <dd> | |
| <p> | |
| Use the value of the <code>core.whitespace</code> configuration variable to | |
| decide what to notice as error. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| String | |
| </dt> | |
| <dd> | |
| <p> | |
| Specify a comma separate list of common whitespace problems to | |
| notice in the same format as the <code>core.whitespace</code> configuration | |
| variable. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_creating_an_archive">Creating an archive</h3> | |
| <div class="sect3"> | |
| <h4 id="_code_export_ignore_code"><code>export-ignore</code></h4> | |
| <div class="paragraph"><p>Files and directories with the attribute <code>export-ignore</code> won’t be added to | |
| archive files.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_code_export_subst_code"><code>export-subst</code></h4> | |
| <div class="paragraph"><p>If the attribute <code>export-subst</code> 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 <code>--pretty=format:</code> of <a href="git-log.html">git-log(1)</a>, | |
| except that they need to be wrapped like this: <code>$Format:PLACEHOLDERS$</code> | |
| in the file. E.g. the string <code>$Format:%H$</code> will be replaced by the | |
| commit hash.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_packing_objects">Packing objects</h3> | |
| <div class="sect3"> | |
| <h4 id="_code_delta_code"><code>delta</code></h4> | |
| <div class="paragraph"><p>Delta compression will not be attempted for blobs for paths with the | |
| attribute <code>delta</code> set to false.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_viewing_files_in_gui_tools">Viewing files in GUI tools</h3> | |
| <div class="sect3"> | |
| <h4 id="_code_encoding_code"><code>encoding</code></h4> | |
| <div class="paragraph"><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="paragraph"><p>If this attribute is not set or has an invalid value, the value of the | |
| <code>gui.encoding</code> configuration variable is used instead | |
| (See <a href="git-config.html">git-config(1)</a>).</p></div> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_using_macro_attributes">USING MACRO ATTRIBUTES</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><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><code>*.jpg -text -diff</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>but that may become cumbersome, when you have many attributes. Using | |
| macro attributes, you can define an attribute that, when set, also | |
| sets or unsets a number of other attributes at the same time. The | |
| system knows a built-in macro attribute, <code>binary</code>:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>*.jpg binary</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>Setting the "binary" attribute also unsets the "text" and "diff" | |
| attributes as above. Note that macro attributes can only be "Set", | |
| though setting one might have the effect of setting or unsetting other | |
| attributes or even returning other attributes to the "Unspecified" | |
| state.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_defining_macro_attributes">DEFINING MACRO ATTRIBUTES</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>Custom macro attributes can be defined only in top-level gitattributes | |
| files (<code>$GIT_DIR/info/attributes</code>, the <code>.gitattributes</code> file at the | |
| top level of the working tree, or the global or system-wide | |
| gitattributes files), not in <code>.gitattributes</code> files in working tree | |
| subdirectories. The built-in macro attribute "binary" is equivalent | |
| to:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>[attr]binary -diff -merge -text</code></pre> | |
| </div></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_examples">EXAMPLES</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>If you have these three <code>gitattributes</code> file:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>(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</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>the attributes given to path <code>t/abc</code> are computed as follows:</p></div> | |
| <div class="olist arabic"><ol class="arabic"> | |
| <li> | |
| <p> | |
| By examining <code>t/.gitattributes</code> (which is in the same | |
| directory as the path in question), Git finds that the first | |
| line matches. <code>merge</code> attribute is set. It also finds that | |
| the second line matches, and attributes <code>foo</code> and <code>bar</code> | |
| are unset. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Then it examines <code>.gitattributes</code> (which is in the parent | |
| directory), and finds that the first line matches, but | |
| <code>t/.gitattributes</code> file already decided how <code>merge</code>, <code>foo</code> | |
| and <code>bar</code> attributes should be given to this path, so it | |
| leaves <code>foo</code> and <code>bar</code> unset. Attribute <code>baz</code> is set. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Finally it examines <code>$GIT_DIR/info/attributes</code>. This file | |
| is used to override the in-tree settings. The first line is | |
| a match, and <code>foo</code> is set, <code>bar</code> is reverted to unspecified | |
| state, and <code>baz</code> is unset. | |
| </p> | |
| </li> | |
| </ol></div> | |
| <div class="paragraph"><p>As the result, the attributes assignment to <code>t/abc</code> becomes:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>foo set to true | |
| bar unspecified | |
| baz set to false | |
| merge set to string value "filfre" | |
| frotz unspecified</code></pre> | |
| </div></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_see_also">SEE ALSO</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p><a href="git-check-attr.html">git-check-attr(1)</a>.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_git">GIT</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div> | |
| </div> | |
| </div> | |
| </div> | |
| <div id="footnotes"><hr /></div> | |
| <div id="footer"> | |
| <div id="footer-text"> | |
| Last updated | |
| 2019-02-06 23:17:45 PST | |
| </div> | |
| </div> | |
| </body> | |
| </html> |