| <?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 10.2.0" /> | |
| <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 overridden 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] | |
| [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] | |
| [--[no-]allow-unrelated-histories] | |
| [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] | |
| [--into-name <branch>] [<commit>…] | |
| <em>git merge</em> (--continue | --abort | --quit)</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 <code>git pull</code> 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. Before the operation, | |
| <code>ORIG_HEAD</code> is set to the tip of the current branch (<code>C</code>).</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>A merge stops if there’s a conflict that cannot be resolved | |
| automatically or if <code>--no-commit</code> was provided when initiating the | |
| merge. At that point you can run <code>git merge --abort</code> or <code>git merge | |
| --continue</code>.</p></div> | |
| <div class="paragraph"><p><code>git merge --abort</code> 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), <code>git merge --abort</code> will in some cases be | |
| unable to reconstruct the original (pre-merge) changes. Therefore:</p></div> | |
| <div class="paragraph"><p><strong>Warning</strong>: Running <code>git merge</code> 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> | |
| </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 and stop just before creating | |
| a merge commit, to give the user a chance to inspect and further | |
| tweak the merge result before committing.</p></div> | |
| <div class="paragraph"><p>Note that fast-forward updates do not create a merge commit and | |
| therefore there is no way to stop those merges with --no-commit. | |
| Thus, if you want to ensure your branch is not changed or updated | |
| by the merge command, use --no-ff with --no-commit.</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"> | |
| --cleanup=<mode> | |
| </dt> | |
| <dd> | |
| <p> | |
| This option determines how the merge message will be cleaned up before | |
| committing. See <a href="git-commit.html">git-commit(1)</a> for more details. In addition, if | |
| the <em><mode></em> is given a value of <code>scissors</code>, scissors will be appended | |
| to <code>MERGE_MSG</code> before being passed on to the commit machinery in the | |
| case of a merge conflict. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --ff | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-ff | |
| </dt> | |
| <dt class="hdlist1"> | |
| --ff-only | |
| </dt> | |
| <dd> | |
| <p> | |
| Specifies how a merge is handled when the merged-in history is | |
| already a descendant of the current history. <code>--ff</code> is the | |
| default unless merging an annotated (and possibly signed) tag | |
| that is not stored in its natural place in the <code>refs/tags/</code> | |
| hierarchy, in which case <code>--no-ff</code> is assumed. | |
| </p> | |
| <div class="paragraph"><p>With <code>--ff</code>, when possible resolve the merge as a fast-forward (only | |
| update the branch pointer to match the merged branch; do not create a | |
| merge commit). When not possible (when the merged-in history is not a | |
| descendant of the current history), create a merge commit.</p></div> | |
| <div class="paragraph"><p>With <code>--no-ff</code>, create a merge commit in all cases, even when the merge | |
| could instead be resolved as a fast-forward.</p></div> | |
| <div class="paragraph"><p>With <code>--ff-only</code>, resolve the merge as a fast-forward when possible. | |
| When not possible, refuse to merge and exit with a non-zero status.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| -S[<keyid>] | |
| </dt> | |
| <dt class="hdlist1"> | |
| --gpg-sign[=<keyid>] | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-gpg-sign | |
| </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. <code>--no-gpg-sign</code> | |
| is useful to countermand both <code>commit.gpgSign</code> configuration variable, | |
| and earlier <code>--gpg-sign</code>. | |
| </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 a <code>Signed-off-by</code> trailer by the committer at the end of the commit | |
| log message. The meaning of a signoff depends on the project | |
| to which you’re committing. For example, it may certify that | |
| the committer has the rights to submit the work under the | |
| project’s license or agrees to some contributor representation, | |
| such as a Developer Certificate of Origin. | |
| (See <a href="https://developercertificate.org">https://developercertificate.org</a> for the one used by the | |
| Linux kernel and Git projects.) Consult the documentation or | |
| leadership of the project to which you’re contributing to | |
| understand how the signoffs are used in that project. | |
| </p> | |
| <div class="paragraph"><p>The --no-signoff option can be used to countermand an earlier --signoff | |
| option on the command 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> | |
| <div class="paragraph"><p>With --squash, --commit is not allowed, and will fail.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --[no-]verify | |
| </dt> | |
| <dd> | |
| <p> | |
| By default, the pre-merge and commit-msg hooks are run. | |
| When <code>--no-verify</code> is given, these are bypassed. | |
| See also <a href="githooks.html">githooks(5)</a>. | |
| </p> | |
| </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 (<code>ort</code> when merging a single head, | |
| <code>octopus</code> 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"> | |
| --autostash | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-autostash | |
| </dt> | |
| <dd> | |
| <p> | |
| Automatically create a temporary stash entry before the operation | |
| begins, record it in the ref <code>MERGE_AUTOSTASH</code> | |
| and apply it after the operation ends. This means | |
| that you can run the operation on a dirty worktree. However, use | |
| with care: the final stash application after a successful | |
| merge might result in non-trivial conflicts. | |
| </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 <code>git fmt-merge-msg</code> command can be | |
| used to give a good default for automated <code>git merge</code> | |
| invocations. The automated message can include the branch description.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --into-name <branch> | |
| </dt> | |
| <dd> | |
| <p> | |
| Prepare the default merge message as if merging to the branch | |
| <code><branch></code>, instead of the name of the real branch to which | |
| the merge is made. | |
| </p> | |
| </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"> | |
| --rerere-autoupdate | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-rerere-autoupdate | |
| </dt> | |
| <dd> | |
| <p> | |
| After the rerere mechanism reuses a recorded resolution on | |
| the current conflict to update the files in the working | |
| tree, allow it to also update the index with the result of | |
| resolution. <code>--no-rerere-autoupdate</code> is a good way to | |
| double-check what <code>rerere</code> did and catch potential | |
| mismerges, before committing the result to the index with a | |
| separate <code>git add</code>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --overwrite-ignore | |
| </dt> | |
| <dt class="hdlist1"> | |
| --no-overwrite-ignore | |
| </dt> | |
| <dd> | |
| <p> | |
| Silently overwrite ignored files from the merge result. This | |
| is the default behavior. Use <code>--no-overwrite-ignore</code> to abort. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --abort | |
| </dt> | |
| <dd> | |
| <p> | |
| Abort the current conflict resolution process, and | |
| try to reconstruct the pre-merge state. If an autostash entry is | |
| present, apply it to the worktree. | |
| </p> | |
| <div class="paragraph"><p>If there were uncommitted worktree changes present when the merge | |
| started, <code>git merge --abort</code> will in some cases be unable to | |
| reconstruct these changes. It is therefore recommended to always | |
| commit or stash your changes before running <code>git merge</code>.</p></div> | |
| <div class="paragraph"><p><code>git merge --abort</code> is equivalent to <code>git reset --merge</code> when | |
| <code>MERGE_HEAD</code> is present unless <code>MERGE_AUTOSTASH</code> is also present in | |
| which case <code>git merge --abort</code> applies the stash entry to the worktree | |
| whereas <code>git reset --merge</code> will save the stashed changes in the stash | |
| list.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --quit | |
| </dt> | |
| <dd> | |
| <p> | |
| Forget about the current merge in progress. Leave the index | |
| and the working tree as-is. If <code>MERGE_AUTOSTASH</code> is present, the | |
| stash entry will be saved to the stash list. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| --continue | |
| </dt> | |
| <dd> | |
| <p> | |
| After a <code>git merge</code> stops due to conflicts you can conclude the | |
| merge by running <code>git merge --continue</code> (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>. | |
| <code>git pull</code> and <code>git merge</code> will stop without doing anything when | |
| local uncommitted changes overlap with files that <code>git pull</code>/<code>git | |
| merge</code> may need to update.</p></div> | |
| <div class="paragraph"><p>To avoid recording unrelated changes in the merge commit, | |
| <code>git pull</code> and <code>git merge</code> 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>, <code>git merge</code> | |
| 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 <code>git | |
| pull</code>: 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 operation; i.e. 3-way | |
| merge results with familiar conflict markers <code><<<</code> <code>===</code> <code>>>></code>. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| A ref named <code>AUTO_MERGE</code> is written, pointing to a tree | |
| corresponding to the current content of the working tree (including | |
| conflict markers for textual conflicts). Note that this ref is only | |
| written when the <em>ort</em> merge strategy is used (the default). | |
| </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, | |
| or cleanly resolved because both sides changed the same way. | |
| <<<<<<< 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 <code>merge.conflictStyle</code> | |
| configuration variable to either "diff3" or "zdiff3". 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 | |
| or cleanly resolved because both sides changed the same way. | |
| Conflict resolution is hard; | |
| let's go shopping. | |
| ||||||| base:sample.txt | |
| or cleanly resolved because both sides changed identically. | |
| Conflict resolution is hard. | |
| ======= | |
| or cleanly resolved because both sides changed the same way. | |
| 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>while in "zdiff3" style, it 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, | |
| or cleanly resolved because both sides changed the same way. | |
| <<<<<<< yours:sample.txt | |
| Conflict resolution is hard; | |
| let's go shopping. | |
| ||||||| base:sample.txt | |
| or cleanly resolved because both sides changed identically. | |
| 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 | |
| <code>git add</code> them to the index. Use <code>git commit</code> or | |
| <code>git merge --continue</code> to seal the deal. The latter command | |
| checks whether there is a (interrupted) merge in progress | |
| before calling <code>git commit</code>. | |
| </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 through the merge with you. | |
| </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. <code>git diff AUTO_MERGE</code> will show what changes you’ve | |
| made so far to resolve textual conflicts. | |
| </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"> | |
| ort | |
| </dt> | |
| <dd> | |
| <p> | |
| This is the default merge strategy when pulling or merging one | |
| branch. This strategy 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 strategy can detect | |
| and handle merges involving renames. It does not make use of | |
| detected copies. The name for this algorithm is an acronym | |
| ("Ostensibly Recursive’s Twin") and came from the fact that it | |
| was written as a replacement for the previous default | |
| algorithm, <code>recursive</code>. | |
| </p> | |
| <div class="paragraph"><p>The <em>ort</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 in 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"> | |
| 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"> | |
| 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"> | |
| 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. It does not make use of detected copies. This was | |
| the default strategy for resolving two heads from Git v0.99.9k | |
| until v2.33.0. | |
| </p> | |
| <div class="paragraph"><p>The <em>recursive</em> strategy takes the same options as <em>ort</em>. However, | |
| there are three additional options that <em>ort</em> ignores (not documented | |
| above) that are potentially useful with the <em>recursive</em> strategy:</p></div> | |
| <div class="dlist"><dl> | |
| <dt class="hdlist1"> | |
| patience | |
| </dt> | |
| <dd> | |
| <p> | |
| Deprecated synonym for <code>diff-algorithm=patience</code>. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| diff-algorithm=[patience|minimal|histogram|myers] | |
| </dt> | |
| <dd> | |
| <p> | |
| Use a different diff algorithm while merging, 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>. Note that <code>ort</code> | |
| specifically uses <code>diff-algorithm=histogram</code>, while <code>recursive</code> | |
| defaults to the <code>diff.algorithm</code> config setting. | |
| </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> | |
| </dl></div> | |
| </dd> | |
| <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. It does not handle renames. | |
| </p> | |
| </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 <code>ort</code> 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>ort</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"> | |
| 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 <code>git merge</code>, but option | |
| values containing whitespace characters are currently not supported. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <div class="paragraph"><p>Everything above this line in this section isn’t included from the | |
| <a href="git-config.html">git-config(1)</a> documentation. The content that follows is the | |
| same as what’s found there:</p></div> | |
| <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. The | |
| "merge" style tends to produce smaller conflict regions than diff3, | |
| both because of the exclusion of the original text, and because | |
| when a subset of lines match on the two sides, they are just pulled | |
| out of the conflict region. Another alternate style, "zdiff3", is | |
| similar to diff3 but removes matching lines on the two sides from | |
| the conflict region when those matching lines appear near either | |
| the beginning or end of a conflict region. | |
| </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. Defaults to true. | |
| </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.suppressDest | |
| </dt> | |
| <dd> | |
| <p> | |
| By adding a glob that matches the names of integration | |
| branches to this multi-valued configuration variable, the | |
| default merge message computed for merges into these | |
| integration branches will omit "into <branch name>" from | |
| its title. | |
| </p> | |
| <div class="paragraph"><p>An element with an empty value can be used to clear the list | |
| of globs accumulated from previous configuration entries. | |
| When there is no <code>merge.suppressDest</code> variable defined, the | |
| default value of <code>master</code> is used for backward compatibility.</p></div> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.renameLimit | |
| </dt> | |
| <dd> | |
| <p> | |
| The number of files to consider in the exhaustive portion of | |
| rename detection during a merge. If not specified, defaults | |
| to the value of diff.renameLimit. If neither | |
| merge.renameLimit nor diff.renameLimit are specified, | |
| currently defaults to 7000. This setting has no effect if | |
| rename detection is turned off. | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| merge.renames | |
| </dt> | |
| <dd> | |
| <p> | |
| Whether 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.directoryRenames | |
| </dt> | |
| <dd> | |
| <p> | |
| Whether Git detects directory renames, affecting what happens at | |
| merge time to new files added to a directory on one side of | |
| history when that directory was renamed on the other side of | |
| history. If merge.directoryRenames is set to "false", directory | |
| rename detection is disabled, meaning that such new files will be | |
| left behind in the old directory. If set to "true", directory | |
| rename detection is enabled, meaning that such new files will be | |
| moved into the new directory. If set to "conflict", a conflict | |
| will be reported for such paths. If merge.renames is false, | |
| merge.directoryRenames is ignored and treated as false. Defaults | |
| to "conflict". | |
| </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.autoStash | |
| </dt> | |
| <dd> | |
| <p> | |
| When set to true, automatically create a temporary stash entry | |
| before the operation begins, and apply it after the operation | |
| ends. This means that you can run merge on a dirty worktree. | |
| However, use with care: the final stash application after a | |
| successful merge might result in non-trivial conflicts. | |
| This option can be overridden by the <code>--no-autostash</code> and | |
| <code>--autostash</code> options of <a href="git-merge.html">git-merge(1)</a>. | |
| Defaults to false. | |
| </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="dlist"><dl> | |
| <dt class="hdlist1"> | |
| <code>araxis</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Araxis Merge (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>bc</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Beyond Compare (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>bc3</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Beyond Compare (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>bc4</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Beyond Compare (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>codecompare</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Code Compare (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>deltawalker</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use DeltaWalker (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>diffmerge</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use DiffMerge (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>diffuse</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Diffuse (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>ecmerge</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use ECMerge (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>emerge</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Emacs' Emerge | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>examdiff</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use ExamDiff Pro (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>guiffy</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Guiffy’s Diff Tool (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>gvimdiff</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use gVim (requires a graphical session) with a custom layout (see <code>git help mergetool</code>'s <code>BACKEND SPECIFIC HINTS</code> section) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>gvimdiff1</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use gVim (requires a graphical session) with a 2 panes layout (LOCAL and REMOTE) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>gvimdiff2</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use gVim (requires a graphical session) with a 3 panes layout (LOCAL, MERGED and REMOTE) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>gvimdiff3</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use gVim (requires a graphical session) where only the MERGED file is shown | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>kdiff3</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use KDiff3 (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>meld</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Meld (requires a graphical session) with optional <code>auto merge</code> (see <code>git help mergetool</code>'s <code>CONFIGURATION</code> section) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>nvimdiff</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Neovim with a custom layout (see <code>git help mergetool</code>'s <code>BACKEND SPECIFIC HINTS</code> section) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>nvimdiff1</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Neovim with a 2 panes layout (LOCAL and REMOTE) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>nvimdiff2</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Neovim with a 3 panes layout (LOCAL, MERGED and REMOTE) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>nvimdiff3</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Neovim where only the MERGED file is shown | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>opendiff</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use FileMerge (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>p4merge</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use HelixCore P4Merge (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>smerge</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Sublime Merge (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>tkdiff</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use TkDiff (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>tortoisemerge</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use TortoiseMerge (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>vimdiff</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Vim with a custom layout (see <code>git help mergetool</code>'s <code>BACKEND SPECIFIC HINTS</code> section) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>vimdiff1</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Vim with a 2 panes layout (LOCAL and REMOTE) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>vimdiff2</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Vim with a 3 panes layout (LOCAL, MERGED and REMOTE) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>vimdiff3</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use Vim where only the MERGED file is shown | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>winmerge</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use WinMerge (requires a graphical session) | |
| </p> | |
| </dd> | |
| <dt class="hdlist1"> | |
| <code>xxdiff</code> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use xxdiff (requires a graphical session) | |
| </p> | |
| </dd> | |
| </dl></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> | |
| </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 | |
| 2024-01-08 14:58:46 PST | |
| </div> | |
| </div> | |
| </body> | |
| </html> |