| <?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>git-merge(1)</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> | |
| git-merge(1) Manual Page | |
| </h1> | |
| <h2>NAME</h2> | |
| <div class="sectionbody"> | |
| <p>git-merge - | |
| Join two or more development histories together | |
| </p> | |
| </div> | |
| </div> | |
| <div id="content"> | |
| <div class="sect1"> | |
| <h2 id="_synopsis">SYNOPSIS</h2> | |
| <div class="sectionbody"> | |
| <div class="verseblock"> | |
| <pre class="content"><em>git merge</em> [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] | |
| [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] | |
| [--[no-]allow-unrelated-histories] | |
| [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>…] | |
| <em>git merge</em> --abort | |
| <em>git merge</em> --continue</pre> | |
| <div class="attribution"> | |
| </div></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_description">DESCRIPTION</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>Incorporates changes from the named commits (since the time their | |
| histories diverged from the current branch) into the current | |
| branch. This command is used by <em>git pull</em> to incorporate changes | |
| from another repository and can be used by hand to merge changes | |
| from one branch into another.</p></div> | |
| <div class="paragraph"><p>Assume the following history exists and the current branch is | |
| "<code>master</code>":</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code> A---B---C topic | |
| / | |
| D---E---F---G master</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>Then "<code>git merge topic</code>" will replay the changes made on the | |
| <code>topic</code> branch since it diverged from <code>master</code> (i.e., <code>E</code>) until | |
| its current commit (<code>C</code>) on top of <code>master</code>, and record the result | |
| in a new commit along with the names of the two parent commits and | |
| a log message from the user describing the changes.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code> A---B---C topic | |
| / \ | |
| D---E---F---G---H master</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>The second syntax ("<code>git merge --abort</code>") can only be run after the | |
| merge has resulted in conflicts. <em>git merge --abort</em> will abort the | |
| merge process and try to reconstruct the pre-merge state. However, | |
| if there were uncommitted changes when the merge started (and | |
| especially if those changes were further modified after the merge | |
| was started), <em>git merge --abort</em> will in some cases be unable to | |
| reconstruct the original (pre-merge) changes. Therefore:</p></div> | |
| <div class="paragraph"><p><strong>Warning</strong>: Running <em>git merge</em> with non-trivial uncommitted changes is | |
| discouraged: while possible, it may leave you in a state that is hard to | |
| back out of in the case of a conflict.</p></div> | |
| <div class="paragraph"><p>The third syntax ("<code>git merge --continue</code>") can only be run after the | |
| merge has resulted in conflicts.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_options">OPTIONS</h2> | |
| <div class="sectionbody"> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| --commit | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-commit | |
| </dt> | |
| <dd> | |
| <p> | |
| Perform the merge and commit the result. This option can | |
| be used to override --no-commit. | |
| </p> | |
| <div class="paragraph"><p>With --no-commit perform the merge but pretend the merge | |
| failed and do not autocommit, to give the user a chance to | |
| inspect and further tweak the merge result before committing.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --edit | |
| </dt> | |
| <dt class="hdlist1"> | |
| -e | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-edit | |
| </dt> | |
| <dd> | |
| <p> | |
| Invoke an editor before committing successful mechanical merge to | |
| further edit the auto-generated merge message, so that the user | |
| can explain and justify the merge. The <code>--no-edit</code> option can be | |
| used to accept the auto-generated message (this is generally | |
| discouraged). | |
| The <code>--edit</code> (or <code>-e</code>) option is still useful if you are | |
| giving a draft message with the <code>-m</code> option from the command line | |
| and want to edit it in the editor. | |
| </p> | |
| <div class="paragraph"><p>Older scripts may depend on the historical behaviour of not allowing the | |
| user to edit the merge log message. They will see an editor opened when | |
| they run <code>git merge</code>. To make it easier to adjust such scripts to the | |
| updated behaviour, the environment variable <code>GIT_MERGE_AUTOEDIT</code> can be | |
| set to <code>no</code> at the beginning of them.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --ff | |
| </dt> | |
| <dd> | |
| <p> | |
| When the merge resolves as a fast-forward, only update the branch | |
| pointer, without creating a merge commit. This is the default | |
| behavior. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --no-ff | |
| </dt> | |
| <dd> | |
| <p> | |
| Create a merge commit even when the merge resolves as a | |
| fast-forward. This is the default behaviour when merging an | |
| annotated (and possibly signed) tag that is not stored in | |
| its natural place in <em>refs/tags/</em> hierarchy. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --ff-only | |
| </dt> | |
| <dd> | |
| <p> | |
| Refuse to merge and exit with a non-zero status unless the | |
| current <code>HEAD</code> is already up to date or the merge can be | |
| resolved as a fast-forward. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| -S[<keyid>] | |
| </dt> | |
| <dt class="hdlist1"> | |
| --gpg-sign[=<keyid>] | |
| </dt> | |
| <dd> | |
| <p> | |
| GPG-sign the resulting merge commit. The <code>keyid</code> argument is | |
| optional and defaults to the committer identity; if specified, | |
| it must be stuck to the option without a space. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --log[=<n>] | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-log | |
| </dt> | |
| <dd> | |
| <p> | |
| In addition to branch names, populate the log message with | |
| one-line descriptions from at most <n> actual commits that are being | |
| merged. See also <a href="git-fmt-merge-msg.html">git-fmt-merge-msg(1)</a>. | |
| </p> | |
| <div class="paragraph"><p>With --no-log do not list one-line descriptions from the | |
| actual commits being merged.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --signoff | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-signoff | |
| </dt> | |
| <dd> | |
| <p> | |
| Add Signed-off-by line by the committer at the end of the commit | |
| log message. The meaning of a signoff depends on the project, | |
| but it typically certifies that committer has | |
| the rights to submit this work under the same license and | |
| agrees to a Developer Certificate of Origin | |
| (see <a href="http://developercertificate.org/">http://developercertificate.org/</a> for more information). | |
| </p> | |
| <div class="paragraph"><p>With --no-signoff do not add a Signed-off-by line.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --stat | |
| </dt> | |
| <dt class="hdlist1"> | |
| -n | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-stat | |
| </dt> | |
| <dd> | |
| <p> | |
| Show a diffstat at the end of the merge. The diffstat is also | |
| controlled by the configuration option merge.stat. | |
| </p> | |
| <div class="paragraph"><p>With -n or --no-stat do not show a diffstat at the end of the | |
| merge.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --squash | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-squash | |
| </dt> | |
| <dd> | |
| <p> | |
| Produce the working tree and index state as if a real merge | |
| happened (except for the merge information), but do not actually | |
| make a commit, move the <code>HEAD</code>, or record <code>$GIT_DIR/MERGE_HEAD</code> | |
| (to cause the next <code>git commit</code> command to create a merge | |
| commit). This allows you to create a single commit on top of | |
| the current branch whose effect is the same as merging another | |
| branch (or more in case of an octopus). | |
| </p> | |
| <div class="paragraph"><p>With --no-squash perform the merge and commit the result. This | |
| option can be used to override --squash.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| -s <strategy> | |
| </dt> | |
| <dt class="hdlist1"> | |
| --strategy=<strategy> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use the given merge strategy; can be supplied more than | |
| once to specify them in the order they should be tried. | |
| If there is no <code>-s</code> option, a built-in list of strategies | |
| is used instead (<em>git merge-recursive</em> when merging a single | |
| head, <em>git merge-octopus</em> otherwise). | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| -X <option> | |
| </dt> | |
| <dt class="hdlist1"> | |
| --strategy-option=<option> | |
| </dt> | |
| <dd> | |
| <p> | |
| Pass merge strategy specific option through to the merge | |
| strategy. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --verify-signatures | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-verify-signatures | |
| </dt> | |
| <dd> | |
| <p> | |
| Verify that the tip commit of the side branch being merged is | |
| signed with a valid key, i.e. a key that has a valid uid: in the | |
| default trust model, this means the signing key has been signed by | |
| a trusted key. If the tip commit of the side branch is not signed | |
| with a valid key, the merge is aborted. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --summary | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-summary | |
| </dt> | |
| <dd> | |
| <p> | |
| Synonyms to --stat and --no-stat; these are deprecated and will be | |
| removed in the future. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| -q | |
| </dt> | |
| <dt class="hdlist1"> | |
| --quiet | |
| </dt> | |
| <dd> | |
| <p> | |
| Operate quietly. Implies --no-progress. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| -v | |
| </dt> | |
| <dt class="hdlist1"> | |
| --verbose | |
| </dt> | |
| <dd> | |
| <p> | |
| Be verbose. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --progress | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-progress | |
| </dt> | |
| <dd> | |
| <p> | |
| Turn progress on/off explicitly. If neither is specified, | |
| progress is shown if standard error is connected to a terminal. | |
| Note that not all merge strategies may support progress | |
| reporting. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --allow-unrelated-histories | |
| </dt> | |
| <dd> | |
| <p> | |
| By default, <code>git merge</code> command refuses to merge histories | |
| that do not share a common ancestor. This option can be | |
| used to override this safety when merging histories of two | |
| projects that started their lives independently. As that is | |
| a very rare occasion, no configuration variable to enable | |
| this by default exists and will not be added. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| -m <msg> | |
| </dt> | |
| <dd> | |
| <p> | |
| Set the commit message to be used for the merge commit (in | |
| case one is created). | |
| </p> | |
| <div class="paragraph"><p>If <code>--log</code> is specified, a shortlog of the commits being merged | |
| will be appended to the specified message.</p></div> | |
| <div class="paragraph"><p>The <em>git fmt-merge-msg</em> command can be | |
| used to give a good default for automated <em>git merge</em> | |
| invocations. The automated message can include the branch description.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| -F <file> | |
| </dt> | |
| <dt class="hdlist1"> | |
| --file=<file> | |
| </dt> | |
| <dd> | |
| <p> | |
| Read the commit message to be used for the merge commit (in | |
| case one is created). | |
| </p> | |
| <div class="paragraph"><p>If <code>--log</code> is specified, a shortlog of the commits being merged | |
| will be appended to the specified message.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --[no-]rerere-autoupdate | |
| </dt> | |
| <dd> | |
| <p> | |
| Allow the rerere mechanism to update the index with the | |
| result of auto-conflict resolution if possible. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --abort | |
| </dt> | |
| <dd> | |
| <p> | |
| Abort the current conflict resolution process, and | |
| try to reconstruct the pre-merge state. | |
| </p> | |
| <div class="paragraph"><p>If there were uncommitted worktree changes present when the merge | |
| started, <em>git merge --abort</em> will in some cases be unable to | |
| reconstruct these changes. It is therefore recommended to always | |
| commit or stash your changes before running <em>git merge</em>.</p></div> | |
| <div class="paragraph"><p><em>git merge --abort</em> is equivalent to <em>git reset --merge</em> when | |
| <code>MERGE_HEAD</code> is present.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --continue | |
| </dt> | |
| <dd> | |
| <p> | |
| After a <em>git merge</em> stops due to conflicts you can conclude the | |
| merge by running <em>git merge --continue</em> (see "HOW TO RESOLVE | |
| CONFLICTS" section below). | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <commit>… | |
| </dt> | |
| <dd> | |
| <p> | |
| Commits, usually other branch heads, to merge into our branch. | |
| Specifying more than one commit will create a merge with | |
| more than two parents (affectionately called an Octopus merge). | |
| </p> | |
| <div class="paragraph"><p>If no commit is given from the command line, merge the remote-tracking | |
| branches that the current branch is configured to use as its upstream. | |
| See also the configuration section of this manual page.</p></div> | |
| <div class="paragraph"><p>When <code>FETCH_HEAD</code> (and no other commit) is specified, the branches | |
| recorded in the <code>.git/FETCH_HEAD</code> file by the previous invocation | |
| of <code>git fetch</code> for merging are merged to the current branch.</p></div> | |
| </dd> | |
| </dl></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_pre_merge_checks">PRE-MERGE CHECKS</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>Before applying outside changes, you should get your own work in | |
| good shape and committed locally, so it will not be clobbered if | |
| there are conflicts. See also <a href="git-stash.html">git-stash(1)</a>. | |
| <em>git pull</em> and <em>git merge</em> will stop without doing anything when | |
| local uncommitted changes overlap with files that <em>git pull</em>/<em>git | |
| merge</em> may need to update.</p></div> | |
| <div class="paragraph"><p>To avoid recording unrelated changes in the merge commit, | |
| <em>git pull</em> and <em>git merge</em> will also abort if there are any changes | |
| registered in the index relative to the <code>HEAD</code> commit. (Special | |
| narrow exceptions to this rule may exist depending on which merge | |
| strategy is in use, but generally, the index must match HEAD.)</p></div> | |
| <div class="paragraph"><p>If all named commits are already ancestors of <code>HEAD</code>, <em>git merge</em> | |
| will exit early with the message "Already up to date."</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_fast_forward_merge">FAST-FORWARD MERGE</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>Often the current branch head is an ancestor of the named commit. | |
| This is the most common case especially when invoked from <em>git | |
| pull</em>: you are tracking an upstream repository, you have committed | |
| no local changes, and now you want to update to a newer upstream | |
| revision. In this case, a new commit is not needed to store the | |
| combined history; instead, the <code>HEAD</code> (along with the index) is | |
| updated to point at the named commit, without creating an extra | |
| merge commit.</p></div> | |
| <div class="paragraph"><p>This behavior can be suppressed with the <code>--no-ff</code> option.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_true_merge">TRUE MERGE</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>Except in a fast-forward merge (see above), the branches to be | |
| merged must be tied together by a merge commit that has both of them | |
| as its parents.</p></div> | |
| <div class="paragraph"><p>A merged version reconciling the changes from all branches to be | |
| merged is committed, and your <code>HEAD</code>, index, and working tree are | |
| updated to it. It is possible to have modifications in the working | |
| tree as long as they do not overlap; the update will preserve them.</p></div> | |
| <div class="paragraph"><p>When it is not obvious how to reconcile the changes, the following | |
| happens:</p></div> | |
| <div class="olist arabic"><ol class="arabic"> | |
| <li> | |
| <p> | |
| The <code>HEAD</code> pointer stays the same. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| The <code>MERGE_HEAD</code> ref is set to point to the other branch head. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Paths that merged cleanly are updated both in the index file and | |
| in your working tree. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| For conflicting paths, the index file records up to three | |
| versions: stage 1 stores the version from the common ancestor, | |
| stage 2 from <code>HEAD</code>, and stage 3 from <code>MERGE_HEAD</code> (you | |
| can inspect the stages with <code>git ls-files -u</code>). The working | |
| tree files contain the result of the "merge" program; i.e. 3-way | |
| merge results with familiar conflict markers <code><<<</code> <code>===</code> <code>>>></code>. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| No other changes are made. In particular, the local | |
| modifications you had before you started merge will stay the | |
| same and the index entries for them stay as they were, | |
| i.e. matching <code>HEAD</code>. | |
| </p> | |
| </li> | |
| </ol></div> | |
| <div class="paragraph"><p>If you tried a merge which resulted in complex conflicts and | |
| want to start over, you can recover with <code>git merge --abort</code>.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_merging_tag">MERGING TAG</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>When merging an annotated (and possibly signed) tag, Git always | |
| creates a merge commit even if a fast-forward merge is possible, and | |
| the commit message template is prepared with the tag message. | |
| Additionally, if the tag is signed, the signature check is reported | |
| as a comment in the message template. See also <a href="git-tag.html">git-tag(1)</a>.</p></div> | |
| <div class="paragraph"><p>When you want to just integrate with the work leading to the commit | |
| that happens to be tagged, e.g. synchronizing with an upstream | |
| release point, you may not want to make an unnecessary merge commit.</p></div> | |
| <div class="paragraph"><p>In such a case, you can "unwrap" the tag yourself before feeding it | |
| to <code>git merge</code>, or pass <code>--ff-only</code> when you do not have any work on | |
| your own. e.g.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>git fetch origin | |
| git merge v1.2.3^0 | |
| git merge --ff-only v1.2.3</code></pre> | |
| </div></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_how_conflicts_are_presented">HOW CONFLICTS ARE PRESENTED</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>During a merge, the working tree files are updated to reflect the result | |
| of the merge. Among the changes made to the common ancestor’s version, | |
| non-overlapping ones (that is, you changed an area of the file while the | |
| other side left that area intact, or vice versa) are incorporated in the | |
| final result verbatim. When both sides made changes to the same area, | |
| however, Git cannot randomly pick one side over the other, and asks you to | |
| resolve it by leaving what both sides did to that area.</p></div> | |
| <div class="paragraph"><p>By default, Git uses the same style as the one used by the "merge" program | |
| from the RCS suite to present such a conflicted hunk, like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>Here are lines that are either unchanged from the common | |
| ancestor, or cleanly resolved because only one side changed. | |
| <<<<<<< yours:sample.txt | |
| Conflict resolution is hard; | |
| let's go shopping. | |
| ======= | |
| Git makes conflict resolution easy. | |
| >>>>>>> theirs:sample.txt | |
| And here is another line that is cleanly resolved or unmodified.</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>The area where a pair of conflicting changes happened is marked with markers | |
| <code><<<<<<<</code>, <code>=======</code>, and <code>>>>>>>></code>. The part before the <code>=======</code> | |
| is typically your side, and the part afterwards is typically their side.</p></div> | |
| <div class="paragraph"><p>The default format does not show what the original said in the conflicting | |
| area. You cannot tell how many lines are deleted and replaced with | |
| Barbie’s remark on your side. The only thing you can tell is that your | |
| side wants to say it is hard and you’d prefer to go shopping, while the | |
| other side wants to claim it is easy.</p></div> | |
| <div class="paragraph"><p>An alternative style can be used by setting the "merge.conflictStyle" | |
| configuration variable to "diff3". In "diff3" style, the above conflict | |
| may look like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>Here are lines that are either unchanged from the common | |
| ancestor, or cleanly resolved because only one side changed. | |
| <<<<<<< yours:sample.txt | |
| Conflict resolution is hard; | |
| let's go shopping. | |
| ||||||| | |
| Conflict resolution is hard. | |
| ======= | |
| Git makes conflict resolution easy. | |
| >>>>>>> theirs:sample.txt | |
| And here is another line that is cleanly resolved or unmodified.</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>In addition to the <code><<<<<<<</code>, <code>=======</code>, and <code>>>>>>>></code> markers, it uses | |
| another <code>|||||||</code> marker that is followed by the original text. You can | |
| tell that the original just stated a fact, and your side simply gave in to | |
| that statement and gave up, while the other side tried to have a more | |
| positive attitude. You can sometimes come up with a better resolution by | |
| viewing the original.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_how_to_resolve_conflicts">HOW TO RESOLVE CONFLICTS</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>After seeing a conflict, you can do two things:</p></div> | |
| <div class="ulist"><ul> | |
| <li> | |
| <p> | |
| Decide not to merge. The only clean-ups you need are to reset | |
| the index file to the <code>HEAD</code> commit to reverse 2. and to clean | |
| up working tree changes made by 2. and 3.; <code>git merge --abort</code> | |
| can be used for this. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Resolve the conflicts. Git will mark the conflicts in | |
| the working tree. Edit the files into shape and | |
| <em>git add</em> them to the index. Use <em>git commit</em> or | |
| <em>git merge --continue</em> to seal the deal. The latter command | |
| checks whether there is a (interrupted) merge in progress | |
| before calling <em>git commit</em>. | |
| </p> | |
| </li> | |
| </ul></div> | |
| <div class="paragraph"><p>You can work through the conflict with a number of tools:</p></div> | |
| <div class="ulist"><ul> | |
| <li> | |
| <p> | |
| Use a mergetool. <code>git mergetool</code> to launch a graphical | |
| mergetool which will work you through the merge. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Look at the diffs. <code>git diff</code> will show a three-way diff, | |
| highlighting changes from both the <code>HEAD</code> and <code>MERGE_HEAD</code> | |
| versions. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Look at the diffs from each branch. <code>git log --merge -p <path></code> | |
| will show diffs first for the <code>HEAD</code> version and then the | |
| <code>MERGE_HEAD</code> version. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Look at the originals. <code>git show :1:filename</code> shows the | |
| common ancestor, <code>git show :2:filename</code> shows the <code>HEAD</code> | |
| version, and <code>git show :3:filename</code> shows the <code>MERGE_HEAD</code> | |
| version. | |
| </p> | |
| </li> | |
| </ul></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_examples">EXAMPLES</h2> | |
| <div class="sectionbody"> | |
| <div class="ulist"><ul> | |
| <li> | |
| <p> | |
| Merge branches <code>fixes</code> and <code>enhancements</code> on top of | |
| the current branch, making an octopus merge: | |
| </p> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>$ git merge fixes enhancements</code></pre> | |
| </div></div> | |
| </li> | |
| <li> | |
| <p> | |
| Merge branch <code>obsolete</code> into the current branch, using <code>ours</code> | |
| merge strategy: | |
| </p> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>$ git merge -s ours obsolete</code></pre> | |
| </div></div> | |
| </li> | |
| <li> | |
| <p> | |
| Merge branch <code>maint</code> into the current branch, but do not make | |
| a new commit automatically: | |
| </p> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><code>$ git merge --no-commit maint</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>This can be used when you want to include further changes to the | |
| merge, or want to write your own merge commit message.</p></div> | |
| <div class="paragraph"><p>You should refrain from abusing this option to sneak substantial | |
| changes into a merge commit. Small fixups like bumping | |
| release/version name would be acceptable.</p></div> | |
| </li> | |
| </ul></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_merge_strategies">MERGE STRATEGIES</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p>The merge mechanism (<code>git merge</code> and <code>git pull</code> commands) allows the | |
| backend <em>merge strategies</em> to be chosen with <code>-s</code> option. Some strategies | |
| can also take their own options, which can be passed by giving <code>-X<option></code> | |
| arguments to <code>git merge</code> and/or <code>git pull</code>.</p></div> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| resolve | |
| </dt> | |
| <dd> | |
| <p> | |
| This can only resolve two heads (i.e. the current branch | |
| and another branch you pulled from) using a 3-way merge | |
| algorithm. It tries to carefully detect criss-cross | |
| merge ambiguities and is considered generally safe and | |
| fast. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| recursive | |
| </dt> | |
| <dd> | |
| <p> | |
| This can only resolve two heads using a 3-way merge | |
| algorithm. When there is more than one common | |
| ancestor that can be used for 3-way merge, it creates a | |
| merged tree of the common ancestors and uses that as | |
| the reference tree for the 3-way merge. This has been | |
| reported to result in fewer merge conflicts without | |
| causing mismerges by tests done on actual merge commits | |
| taken from Linux 2.6 kernel development history. | |
| Additionally this can detect and handle merges involving | |
| renames, but currently cannot make use of detected | |
| copies. This is the default merge strategy when pulling | |
| or merging one branch. | |
| </p> | |
| <div class="paragraph"><p>The <em>recursive</em> strategy can take the following options:</p></div> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| ours | |
| </dt> | |
| <dd> | |
| <p> | |
| This option forces conflicting hunks to be auto-resolved cleanly by | |
| favoring <em>our</em> version. Changes from the other tree that do not | |
| conflict with our side are reflected to the merge result. | |
| For a binary file, the entire contents are taken from our side. | |
| </p> | |
| <div class="paragraph"><p>This should not be confused with the <em>ours</em> merge strategy, which does not | |
| even look at what the other tree contains at all. It discards everything | |
| the other tree did, declaring <em>our</em> history contains all that happened in it.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| theirs | |
| </dt> | |
| <dd> | |
| <p> | |
| This is the opposite of <em>ours</em>; note that, unlike <em>ours</em>, there is | |
| no <em>theirs</em> merge strategy to confuse this merge option with. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| patience | |
| </dt> | |
| <dd> | |
| <p> | |
| With this option, <em>merge-recursive</em> spends a little extra time | |
| to avoid mismerges that sometimes occur due to unimportant | |
| matching lines (e.g., braces from distinct functions). Use | |
| this when the branches to be merged have diverged wildly. | |
| See also <a href="git-diff.html">git-diff(1)</a> <code>--patience</code>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| diff-algorithm=[patience|minimal|histogram|myers] | |
| </dt> | |
| <dd> | |
| <p> | |
| Tells <em>merge-recursive</em> to use a different diff algorithm, which | |
| can help avoid mismerges that occur due to unimportant matching | |
| lines (such as braces from distinct functions). See also | |
| <a href="git-diff.html">git-diff(1)</a> <code>--diff-algorithm</code>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| ignore-space-change | |
| </dt> | |
| <dt class="hdlist1"> | |
| ignore-all-space | |
| </dt> | |
| <dt class="hdlist1"> | |
| ignore-space-at-eol | |
| </dt> | |
| <dt class="hdlist1"> | |
| ignore-cr-at-eol | |
| </dt> | |
| <dd> | |
| <p> | |
| Treats lines with the indicated type of whitespace change as | |
| unchanged for the sake of a three-way merge. Whitespace | |
| changes mixed with other changes to a line are not ignored. | |
| See also <a href="git-diff.html">git-diff(1)</a> <code>-b</code>, <code>-w</code>, | |
| <code>--ignore-space-at-eol</code>, and <code>--ignore-cr-at-eol</code>. | |
| </p> | |
| <div class="ulist"><ul> | |
| <li> | |
| <p> | |
| If <em>their</em> version only introduces whitespace changes to a line, | |
| <em>our</em> version is used; | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| If <em>our</em> version introduces whitespace changes but <em>their</em> | |
| version includes a substantial change, <em>their</em> version is used; | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Otherwise, the merge proceeds in the usual way. | |
| </p> | |
| </li> | |
| </ul></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| renormalize | |
| </dt> | |
| <dd> | |
| <p> | |
| This runs a virtual check-out and check-in of all three stages | |
| of a file when resolving a three-way merge. This option is | |
| meant to be used when merging branches with different clean | |
| filters or end-of-line normalization rules. See "Merging | |
| branches with differing checkin/checkout attributes" in | |
| <a href="gitattributes.html">gitattributes(5)</a> for details. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| no-renormalize | |
| </dt> | |
| <dd> | |
| <p> | |
| Disables the <code>renormalize</code> option. This overrides the | |
| <code>merge.renormalize</code> configuration variable. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| no-renames | |
| </dt> | |
| <dd> | |
| <p> | |
| Turn off rename detection. This overrides the <code>merge.renames</code> | |
| configuration variable. | |
| See also <a href="git-diff.html">git-diff(1)</a> <code>--no-renames</code>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| find-renames[=<n>] | |
| </dt> | |
| <dd> | |
| <p> | |
| Turn on rename detection, optionally setting the similarity | |
| threshold. This is the default. This overrides the | |
| <em>merge.renames</em> configuration variable. | |
| See also <a href="git-diff.html">git-diff(1)</a> <code>--find-renames</code>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| rename-threshold=<n> | |
| </dt> | |
| <dd> | |
| <p> | |
| Deprecated synonym for <code>find-renames=<n></code>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| subtree[=<path>] | |
| </dt> | |
| <dd> | |
| <p> | |
| This option is a more advanced form of <em>subtree</em> strategy, where | |
| the strategy makes a guess on how two trees must be shifted to | |
| match with each other when merging. Instead, the specified path | |
| is prefixed (or stripped from the beginning) to make the shape of | |
| two trees to match. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| octopus | |
| </dt> | |
| <dd> | |
| <p> | |
| This resolves cases with more than two heads, but refuses to do | |
| a complex merge that needs manual resolution. It is | |
| primarily meant to be used for bundling topic branch | |
| heads together. This is the default merge strategy when | |
| pulling or merging more than one branch. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| ours | |
| </dt> | |
| <dd> | |
| <p> | |
| This resolves any number of heads, but the resulting tree of the | |
| merge is always that of the current branch head, effectively | |
| ignoring all changes from all other branches. It is meant to | |
| be used to supersede old development history of side | |
| branches. Note that this is different from the -Xours option to | |
| the <em>recursive</em> merge strategy. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| subtree | |
| </dt> | |
| <dd> | |
| <p> | |
| This is a modified recursive strategy. When merging trees A and | |
| B, if B corresponds to a subtree of A, B is first adjusted to | |
| match the tree structure of A, instead of reading the trees at | |
| the same level. This adjustment is also done to the common | |
| ancestor tree. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <div class="paragraph"><p>With the strategies that use 3-way merge (including the default, <em>recursive</em>), | |
| if a change is made on both branches, but later reverted on one of the | |
| branches, that change will be present in the merged result; some people find | |
| this behavior confusing. It occurs because only the heads and the merge base | |
| are considered when performing a merge, not the individual commits. The merge | |
| algorithm therefore considers the reverted change as no change at all, and | |
| substitutes the changed version instead.</p></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_configuration">CONFIGURATION</h2> | |
| <div class="sectionbody"> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| merge.conflictStyle | |
| </dt> | |
| <dd> | |
| <p> | |
| Specify the style in which conflicted hunks are written out to | |
| working tree files upon merge. The default is "merge", which | |
| shows a <code><<<<<<<</code> conflict marker, changes made by one side, | |
| a <code>=======</code> marker, changes made by the other side, and then | |
| a <code>>>>>>>></code> marker. An alternate style, "diff3", adds a <code>|||||||</code> | |
| marker and the original text before the <code>=======</code> marker. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.defaultToUpstream | |
| </dt> | |
| <dd> | |
| <p> | |
| If merge is called without any commit argument, merge the upstream | |
| branches configured for the current branch by using their last | |
| observed values stored in their remote-tracking branches. | |
| The values of the <code>branch.<current branch>.merge</code> that name the | |
| branches at the remote named by <code>branch.<current branch>.remote</code> | |
| are consulted, and then they are mapped via <code>remote.<remote>.fetch</code> | |
| to their corresponding remote-tracking branches, and the tips of | |
| these tracking branches are merged. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.ff | |
| </dt> | |
| <dd> | |
| <p> | |
| By default, Git does not create an extra merge commit when merging | |
| a commit that is a descendant of the current commit. Instead, the | |
| tip of the current branch is fast-forwarded. When set to <code>false</code>, | |
| this variable tells Git to create an extra merge commit in such | |
| a case (equivalent to giving the <code>--no-ff</code> option from the command | |
| line). When set to <code>only</code>, only such fast-forward merges are | |
| allowed (equivalent to giving the <code>--ff-only</code> option from the | |
| command line). | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.verifySignatures | |
| </dt> | |
| <dd> | |
| <p> | |
| If true, this is equivalent to the --verify-signatures command | |
| line option. See <a href="git-merge.html">git-merge(1)</a> for details. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.branchdesc | |
| </dt> | |
| <dd> | |
| <p> | |
| In addition to branch names, populate the log message with | |
| the branch description text associated with them. Defaults | |
| to false. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.log | |
| </dt> | |
| <dd> | |
| <p> | |
| In addition to branch names, populate the log message with at | |
| most the specified number of one-line descriptions from the | |
| actual commits that are being merged. Defaults to false, and | |
| true is a synonym for 20. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.renameLimit | |
| </dt> | |
| <dd> | |
| <p> | |
| The number of files to consider when performing rename detection | |
| during a merge; if not specified, defaults to the value of | |
| diff.renameLimit. This setting has no effect if rename detection | |
| is turned off. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.renames | |
| </dt> | |
| <dd> | |
| <p> | |
| Whether and how Git detects renames. If set to "false", | |
| rename detection is disabled. If set to "true", basic rename | |
| detection is enabled. Defaults to the value of diff.renames. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.renormalize | |
| </dt> | |
| <dd> | |
| <p> | |
| Tell Git that canonical representation of files in the | |
| repository has changed over time (e.g. earlier commits record | |
| text files with CRLF line endings, but recent ones use LF line | |
| endings). In such a repository, Git can convert the data | |
| recorded in commits to a canonical form before performing a | |
| merge to reduce unnecessary conflicts. For more information, | |
| see section "Merging branches with differing checkin/checkout | |
| attributes" in <a href="gitattributes.html">gitattributes(5)</a>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.stat | |
| </dt> | |
| <dd> | |
| <p> | |
| Whether to print the diffstat between ORIG_HEAD and the merge result | |
| at the end of the merge. True by default. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.tool | |
| </dt> | |
| <dd> | |
| <p> | |
| Controls which merge tool is used by <a href="git-mergetool.html">git-mergetool(1)</a>. | |
| The list below shows the valid built-in values. | |
| Any other value is treated as a custom merge tool and requires | |
| that a corresponding mergetool.<tool>.cmd variable is defined. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.guitool | |
| </dt> | |
| <dd> | |
| <p> | |
| Controls which merge tool is used by <a href="git-mergetool.html">git-mergetool(1)</a> when the | |
| -g/--gui flag is specified. The list below shows the valid built-in values. | |
| Any other value is treated as a custom merge tool and requires that a | |
| corresponding mergetool.<guitool>.cmd variable is defined. | |
| </p> | |
| <div class="ulist"><ul> | |
| <li> | |
| <p> | |
| araxis | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| bc | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| bc3 | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| codecompare | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| deltawalker | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| diffmerge | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| diffuse | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| ecmerge | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| emerge | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| examdiff | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| guiffy | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| gvimdiff | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| gvimdiff2 | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| gvimdiff3 | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| kdiff3 | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| meld | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| opendiff | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| p4merge | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| tkdiff | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| tortoisemerge | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| vimdiff | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| vimdiff2 | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| vimdiff3 | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| winmerge | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| xxdiff | |
| </p> | |
| </li> | |
| </ul></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.verbosity | |
| </dt> | |
| <dd> | |
| <p> | |
| Controls the amount of output shown by the recursive merge | |
| strategy. Level 0 outputs nothing except a final error | |
| message if conflicts were detected. Level 1 outputs only | |
| conflicts, 2 outputs conflicts and file changes. Level 5 and | |
| above outputs debugging information. The default is level 2. | |
| Can be overridden by the <code>GIT_MERGE_VERBOSITY</code> environment variable. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.<driver>.name | |
| </dt> | |
| <dd> | |
| <p> | |
| Defines a human-readable name for a custom low-level | |
| merge driver. See <a href="gitattributes.html">gitattributes(5)</a> for details. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.<driver>.driver | |
| </dt> | |
| <dd> | |
| <p> | |
| Defines the command that implements a custom low-level | |
| merge driver. See <a href="gitattributes.html">gitattributes(5)</a> for details. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.<driver>.recursive | |
| </dt> | |
| <dd> | |
| <p> | |
| Names a low-level merge driver to be used when | |
| performing an internal merge between common ancestors. | |
| See <a href="gitattributes.html">gitattributes(5)</a> for details. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| branch.<name>.mergeOptions | |
| </dt> | |
| <dd> | |
| <p> | |
| Sets default options for merging into branch <name>. The syntax and | |
| supported options are the same as those of <em>git merge</em>, but option | |
| values containing whitespace characters are currently not supported. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_see_also">SEE ALSO</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"><p><a href="git-fmt-merge-msg.html">git-fmt-merge-msg(1)</a>, <a href="git-pull.html">git-pull(1)</a>, | |
| <a href="gitattributes.html">gitattributes(5)</a>, | |
| <a href="git-reset.html">git-reset(1)</a>, | |
| <a href="git-diff.html">git-diff(1)</a>, <a href="git-ls-files.html">git-ls-files(1)</a>, | |
| <a href="git-add.html">git-add(1)</a>, <a href="git-rm.html">git-rm(1)</a>, | |
| <a href="git-mergetool.html">git-mergetool(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 | |
| 2018-11-13 06:05:48 PST | |
| </div> | |
| </div> | |
| </body> | |
| </html> |