<!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.9" /> | |
<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"> | |
/*<![CDATA[*/ | |
var asciidoc = { // Namespace. | |
///////////////////////////////////////////////////////////////////// | |
// Table Of Contents generator | |
///////////////////////////////////////////////////////////////////// | |
/* Author: Mihai Bazon, September 2002 | |
* http://students.infoiasi.ro/~mishoo | |
* | |
* Table Of Content generator | |
* Version: 0.4 | |
* | |
* Feel free to use this script under the terms of the GNU General Public | |
* License, as long as you do not remove or alter this notice. | |
*/ | |
/* modified by Troy D. Hanson, September 2006. License: GPL */ | |
/* modified by Stuart Rackham, 2006, 2009. License: GPL */ | |
// toclevels = 1..4. | |
toc: function (toclevels) { | |
function getText(el) { | |
var text = ""; | |
for (var i = el.firstChild; i != null; i = i.nextSibling) { | |
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants. | |
text += i.data; | |
else if (i.firstChild != null) | |
text += getText(i); | |
} | |
return text; | |
} | |
function TocEntry(el, text, toclevel) { | |
this.element = el; | |
this.text = text; | |
this.toclevel = toclevel; | |
} | |
function tocEntries(el, toclevels) { | |
var result = new Array; | |
var re = new RegExp('[hH]([1-'+(toclevels+1)+'])'); | |
// 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>] [<commit>…] | |
<em>git merge</em> <msg> HEAD <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 (<msg> <code>HEAD</code> <commit>…) is supported for | |
historical reasons. Do not use it from the command line or in | |
new scripts. It is the same as <code>git merge -m <msg> <commit>...</code>.</p></div> | |
<div class="paragraph"><p>The third 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 fourth 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. | |
</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"> | |
--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"> | |
--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"> | |
-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"> | |
-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"> | |
--[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. (One | |
exception is when the changed index entries are in the state that | |
would result from the merge already.)</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> to seal the deal. | |
</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. 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>. | |
</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> | |
<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>, and | |
<code>--ignore-space-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. | |
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. | |
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.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. | |
</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> | |
<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> | |
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 2016-12-27 14:37:07 PST | |
</div> | |
</div> | |
</body> | |
</html> |