<?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>gitfaq(7)</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"> | |
/*<![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> | |
gitfaq(7) Manual Page | |
</h1> | |
<h2>NAME</h2> | |
<div class="sectionbody"> | |
<p>gitfaq - | |
Frequently asked questions about using Git | |
</p> | |
</div> | |
</div> | |
<div id="content"> | |
<div class="sect1"> | |
<h2 id="_synopsis">SYNOPSIS</h2> | |
<div class="sectionbody"> | |
<div class="paragraph"><p>gitfaq</p></div> | |
</div> | |
</div> | |
<div class="sect1"> | |
<h2 id="_description">DESCRIPTION</h2> | |
<div class="sectionbody"> | |
<div class="paragraph"><p>The examples in this FAQ assume a standard POSIX shell, like <code>bash</code> or <code>dash</code>, | |
and a user, A U Thor, who has the account <code>author</code> on the hosting provider | |
<code>git.example.org</code>.</p></div> | |
</div> | |
</div> | |
<div class="sect1"> | |
<h2 id="_configuration">Configuration</h2> | |
<div class="sectionbody"> | |
<div class="dlist" id="user-name"><dl> | |
<dt class="hdlist1"> | |
What should I put in <code>user.name</code>? | |
</dt> | |
<dd> | |
<p> | |
You should put your personal name, generally a form using a given name | |
and family name. For example, the current maintainer of Git uses "Junio | |
C Hamano". This will be the name portion that is stored in every commit | |
you make. | |
</p> | |
<div class="paragraph"><p>This configuration doesn’t have any effect on authenticating to remote services; | |
for that, see <code>credential.username</code> in <a href="git-config.html">git-config(1)</a>.</p></div> | |
</dd> | |
<dt class="hdlist1"> | |
What does <code>http.postBuffer</code> really do? | |
</dt> | |
<dd> | |
<p> | |
This option changes the size of the buffer that Git uses when pushing | |
data to a remote over HTTP or HTTPS. If the data is larger than this | |
size, libcurl, which handles the HTTP support for Git, will use chunked | |
transfer encoding since it isn’t known ahead of time what the size of | |
the pushed data will be. | |
</p> | |
<div class="paragraph" id="http-postbuffer"><p>Leaving this value at the default size is fine unless you know that either the | |
remote server or a proxy in the middle doesn’t support HTTP/1.1 (which | |
introduced the chunked transfer encoding) or is known to be broken with chunked | |
data. This is often (erroneously) suggested as a solution for generic push | |
problems, but since almost every server and proxy supports at least HTTP/1.1, | |
raising this value usually doesn’t solve most push problems. A server or proxy | |
that didn’t correctly support HTTP/1.1 and chunked transfer encoding wouldn’t be | |
that useful on the Internet today, since it would break lots of traffic.</p></div> | |
<div class="paragraph"><p>Note that increasing this value will increase the memory used on every relevant | |
push that Git does over HTTP or HTTPS, since the entire buffer is allocated | |
regardless of whether or not it is all used. Thus, it’s best to leave it at the | |
default unless you are sure you need a different value.</p></div> | |
</dd> | |
<dt class="hdlist1"> | |
How do I configure a different editor? | |
</dt> | |
<dd> | |
<p> | |
If you haven’t specified an editor specifically for Git, it will by default | |
use the editor you’ve configured using the <code>VISUAL</code> or <code>EDITOR</code> environment | |
variables, or if neither is specified, the system default (which is usually | |
<code>vi</code>). Since some people find <code>vi</code> difficult to use or prefer a different | |
editor, it may be desirable to change the editor used. | |
</p> | |
<div class="paragraph" id="configure-editor"><p>If you want to configure a general editor for most programs which need one, you | |
can edit your shell configuration (e.g., <code>~/.bashrc</code> or <code>~/.zshenv</code>) to contain | |
a line setting the <code>EDITOR</code> or <code>VISUAL</code> environment variable to an appropriate | |
value. For example, if you prefer the editor <code>nano</code>, then you could write the | |
following:</p></div> | |
<div class="listingblock"> | |
<div class="content"> | |
<pre><code>export VISUAL=nano</code></pre> | |
</div></div> | |
<div class="paragraph"><p>If you want to configure an editor specifically for Git, you can either set the | |
<code>core.editor</code> configuration value or the <code>GIT_EDITOR</code> environment variable. You | |
can see <a href="git-var.html">git-var(1)</a> for details on the order in which these options are | |
consulted.</p></div> | |
<div class="paragraph"><p>Note that in all cases, the editor value will be passed to the shell, so any | |
arguments containing spaces should be appropriately quoted. Additionally, if | |
your editor normally detaches from the terminal when invoked, you should specify | |
it with an argument that makes it not do that, or else Git will not see any | |
changes. An example of a configuration addressing both of these issues on | |
Windows would be the configuration <code>"C:\Program Files\Vim\gvim.exe" --nofork</code>, | |
which quotes the filename with spaces and specifies the <code>--nofork</code> option to | |
avoid backgrounding the process.</p></div> | |
</dd> | |
</dl></div> | |
</div> | |
</div> | |
<div class="sect1"> | |
<h2 id="_credentials">Credentials</h2> | |
<div class="sectionbody"> | |
<div class="dlist" id="http-credentials"><dl> | |
<dt class="hdlist1"> | |
How do I specify my credentials when pushing over HTTP? | |
</dt> | |
<dd> | |
<p> | |
The easiest way to do this is to use a credential helper via the | |
<code>credential.helper</code> configuration. Most systems provide a standard | |
choice to integrate with the system credential manager. For example, | |
Git for Windows provides the <code>wincred</code> credential manager, macOS has the | |
<code>osxkeychain</code> credential manager, and Unix systems with a standard | |
desktop environment can use the <code>libsecret</code> credential manager. All of | |
these store credentials in an encrypted store to keep your passwords or | |
tokens secure. | |
</p> | |
<div class="paragraph"><p>In addition, you can use the <code>store</code> credential manager which stores in a file | |
in your home directory, or the <code>cache</code> credential manager, which does not | |
permanently store your credentials, but does prevent you from being prompted for | |
them for a certain period of time.</p></div> | |
<div class="paragraph"><p>You can also just enter your password when prompted. While it is possible to | |
place the password (which must be percent-encoded) in the URL, this is not | |
particularly secure and can lead to accidental exposure of credentials, so it is | |
not recommended.</p></div> | |
</dd> | |
<dt class="hdlist1"> | |
How do I read a password or token from an environment variable? | |
</dt> | |
<dd> | |
<p> | |
The <code>credential.helper</code> configuration option can also take an arbitrary | |
shell command that produces the credential protocol on standard output. | |
This is useful when passing credentials into a container, for example. | |
</p> | |
<div class="paragraph" id="http-credentials-environment"><p>Such a shell command can be specified by starting the option value with an | |
exclamation point. If your password or token were stored in the <code>GIT_TOKEN</code>, | |
you could run the following command to set your credential helper:</p></div> | |
<div class="listingblock"> | |
<div class="content"> | |
<pre><code>$ git config credential.helper \ | |
'!f() { echo username=author; echo "password=$GIT_TOKEN"; };f'</code></pre> | |
</div></div> | |
</dd> | |
<dt class="hdlist1"> | |
How do I change the password or token I’ve saved in my credential manager? | |
</dt> | |
<dd> | |
<p> | |
Usually, if the password or token is invalid, Git will erase it and | |
prompt for a new one. However, there are times when this doesn’t always | |
happen. To change the password or token, you can erase the existing | |
credentials and then Git will prompt for new ones. To erase | |
credentials, use a syntax like the following (substituting your username | |
and the hostname): | |
</p> | |
<div class="listingblock" id="http-reset-credentials"> | |
<div class="content"> | |
<pre><code>$ echo url=https://author@git.example.org | git credential reject</code></pre> | |
</div></div> | |
</dd> | |
<dt class="hdlist1"> | |
How do I use multiple accounts with the same hosting provider using HTTP? | |
</dt> | |
<dd> | |
<p> | |
Usually the easiest way to distinguish between these accounts is to use | |
the username in the URL. For example, if you have the accounts <code>author</code> | |
and <code>committer</code> on <code>git.example.org</code>, you can use the URLs | |
<a href="https://author@git.example.org/org1/project1.git">https://author@git.example.org/org1/project1.git</a> and | |
<a href="https://committer@git.example.org/org2/project2.git">https://committer@git.example.org/org2/project2.git</a>. This way, when you | |
use a credential helper, it will automatically try to look up the | |
correct credentials for your account. If you already have a remote set | |
up, you can change the URL with something like <code>git remote set-url | |
origin https://author@git.example.org/org1/project1.git</code> (see | |
<a href="git-remote.html">git-remote(1)</a> for details). | |
</p> | |
</dd> | |
<dt class="hdlist1"> | |
How do I use multiple accounts with the same hosting provider using SSH? | |
</dt> | |
<dd> | |
<p> | |
With most hosting providers that support SSH, a single key pair uniquely | |
identifies a user. Therefore, to use multiple accounts, it’s necessary | |
to create a key pair for each account. If you’re using a reasonably | |
modern OpenSSH version, you can create a new key pair with something | |
like <code>ssh-keygen -t ed25519 -f ~/.ssh/id_committer</code>. You can then | |
register the public key (in this case, <code>~/.ssh/id_committer.pub</code>; note | |
the <code>.pub</code>) with the hosting provider. | |
</p> | |
<div class="paragraph" id="multiple-accounts-ssh"><p>Most hosting providers use a single SSH account for pushing; that is, all users | |
push to the <code>git</code> account (e.g., <code>git@git.example.org</code>). If that’s the case for | |
your provider, you can set up multiple aliases in SSH to make it clear which key | |
pair to use. For example, you could write something like the following in | |
<code>~/.ssh/config</code>, substituting the proper private key file:</p></div> | |
<div class="listingblock"> | |
<div class="content"> | |
<pre><code># This is the account for author on git.example.org. | |
Host example_author | |
HostName git.example.org | |
User git | |
# This is the key pair registered for author with git.example.org. | |
IdentityFile ~/.ssh/id_author | |
IdentitiesOnly yes | |
# This is the account for committer on git.example.org. | |
Host example_committer | |
HostName git.example.org | |
User git | |
# This is the key pair registered for committer with git.example.org. | |
IdentityFile ~/.ssh/id_committer | |
IdentitiesOnly yes</code></pre> | |
</div></div> | |
<div class="paragraph"><p>Then, you can adjust your push URL to use <code>git@example_author</code> or | |
<code>git@example_committer</code> instead of <code>git@example.org</code> (e.g., <code>git remote set-url | |
git@example_author:org1/project1.git</code>).</p></div> | |
</dd> | |
</dl></div> | |
</div> | |
</div> | |
<div class="sect1"> | |
<h2 id="_common_issues">Common Issues</h2> | |
<div class="sectionbody"> | |
<div class="dlist" id="last-commit-amend"><dl> | |
<dt class="hdlist1"> | |
I’ve made a mistake in the last commit. How do I change it? | |
</dt> | |
<dd> | |
<p> | |
You can make the appropriate change to your working tree, run <code>git add | |
<file></code> or <code>git rm <file></code>, as appropriate, to stage it, and then <code>git | |
commit --amend</code>. Your change will be included in the commit, and you’ll | |
be prompted to edit the commit message again; if you wish to use the | |
original message verbatim, you can use the <code>--no-edit</code> option to <code>git | |
commit</code> in addition, or just save and quit when your editor opens. | |
</p> | |
</dd> | |
<dt class="hdlist1"> | |
I’ve made a change with a bug and it’s been included in the main branch. How should I undo it? | |
</dt> | |
<dd> | |
<p> | |
The usual way to deal with this is to use <code>git revert</code>. This preserves | |
the history that the original change was made and was a valuable | |
contribution, but also introduces a new commit that undoes those changes | |
because the original had a problem. The commit message of the revert | |
indicates the commit which was reverted and is usually edited to include | |
an explanation as to why the revert was made. | |
</p> | |
</dd> | |
<dt class="hdlist1"> | |
How do I ignore changes to a tracked file? | |
</dt> | |
<dd> | |
<p> | |
Git doesn’t provide a way to do this. The reason is that if Git needs | |
to overwrite this file, such as during a checkout, it doesn’t know | |
whether the changes to the file are precious and should be kept, or | |
whether they are irrelevant and can safely be destroyed. Therefore, it | |
has to take the safe route and always preserve them. | |
</p> | |
<div class="paragraph" id="ignore-tracked-files"><p>It’s tempting to try to use certain features of <code>git update-index</code>, namely the | |
assume-unchanged and skip-worktree bits, but these don’t work properly for this | |
purpose and shouldn’t be used this way.</p></div> | |
<div class="paragraph"><p>If your goal is to modify a configuration file, it can often be helpful to have | |
a file checked into the repository which is a template or set of defaults which | |
can then be copied alongside and modified as appropriate. This second, modified | |
file is usually ignored to prevent accidentally committing it.</p></div> | |
</dd> | |
<dt class="hdlist1"> | |
I asked Git to ignore various files, yet they are still tracked | |
</dt> | |
<dd> | |
<p> | |
A <code>gitignore</code> file ensures that certain file(s) which are not | |
tracked by Git remain untracked. However, sometimes particular | |
file(s) may have been tracked before adding them into the | |
<code>.gitignore</code>, hence they still remain tracked. To untrack and | |
ignore files/patterns, use <code>git rm --cached <file/pattern></code> | |
and add a pattern to <code>.gitignore</code> that matches the <file>. | |
See <a href="gitignore.html">gitignore(5)</a> for details. | |
</p> | |
</dd> | |
<dt class="hdlist1"> | |
How do I know if I want to do a fetch or a pull? | |
</dt> | |
<dd> | |
<p> | |
A fetch stores a copy of the latest changes from the remote | |
repository, without modifying the working tree or current branch. | |
You can then at your leisure inspect, merge, rebase on top of, or | |
ignore the upstream changes. A pull consists of a fetch followed | |
immediately by either a merge or rebase. See <a href="git-pull.html">git-pull(1)</a>. | |
</p> | |
</dd> | |
</dl></div> | |
</div> | |
</div> | |
<div class="sect1"> | |
<h2 id="fetching-and-pulling">Merging and Rebasing</h2> | |
<div class="sectionbody"> | |
<div class="dlist" id="long-running-squash-merge"><dl> | |
<dt class="hdlist1"> | |
What kinds of problems can occur when merging long-lived branches with squash merges? | |
</dt> | |
<dd> | |
<p> | |
In general, there are a variety of problems that can occur when using squash | |
merges to merge two branches multiple times. These can include seeing extra | |
commits in <code>git log</code> output, with a GUI, or when using the <code>...</code> notation to | |
express a range, as well as the possibility of needing to re-resolve conflicts | |
again and again. | |
</p> | |
<div class="paragraph"><p>When Git does a normal merge between two branches, it considers exactly three | |
points: the two branches and a third commit, called the <em>merge base</em>, which is | |
usually the common ancestor of the commits. The result of the merge is the sum | |
of the changes between the merge base and each head. When you merge two | |
branches with a regular merge commit, this results in a new commit which will | |
end up as a merge base when they’re merged again, because there is now a new | |
common ancestor. Git doesn’t have to consider changes that occurred before the | |
merge base, so you don’t have to re-resolve any conflicts you resolved before.</p></div> | |
<div class="paragraph"><p>When you perform a squash merge, a merge commit isn’t created; instead, the | |
changes from one side are applied as a regular commit to the other side. This | |
means that the merge base for these branches won’t have changed, and so when Git | |
goes to perform its next merge, it considers all of the changes that it | |
considered the last time plus the new changes. That means any conflicts may | |
need to be re-resolved. Similarly, anything using the <code>...</code> notation in <code>git | |
diff</code>, <code>git log</code>, or a GUI will result in showing all of the changes since the | |
original merge base.</p></div> | |
<div class="paragraph"><p>As a consequence, if you want to merge two long-lived branches repeatedly, it’s | |
best to always use a regular merge commit.</p></div> | |
</dd> | |
<dt class="hdlist1"> | |
If I make a change on two branches but revert it on one, why does the merge of those branches include the change? | |
</dt> | |
<dd> | |
<p> | |
By default, when Git does a merge, it uses a strategy called the <code>ort</code> | |
strategy, which does a fancy three-way merge. In such a case, when Git | |
performs the merge, it considers exactly three points: the two heads and a | |
third point, called the <em>merge base</em>, which is usually the common ancestor of | |
those commits. Git does not consider the history or the individual commits | |
that have happened on those branches at all. | |
</p> | |
<div class="paragraph" id="merge-two-revert-one"><p>As a result, if both sides have a change and one side has reverted that change, | |
the result is to include the change. This is because the code has changed on | |
one side and there is no net change on the other, and in this scenario, Git | |
adopts the change.</p></div> | |
<div class="paragraph"><p>If this is a problem for you, you can do a rebase instead, rebasing the branch | |
with the revert onto the other branch. A rebase in this scenario will revert | |
the change, because a rebase applies each individual commit, including the | |
revert. Note that rebases rewrite history, so you should avoid rebasing | |
published branches unless you’re sure you’re comfortable with that. See the | |
NOTES section in <a href="git-rebase.html">git-rebase(1)</a> for more details.</p></div> | |
</dd> | |
</dl></div> | |
</div> | |
</div> | |
<div class="sect1"> | |
<h2 id="_hooks">Hooks</h2> | |
<div class="sectionbody"> | |
<div class="dlist" id="restrict-with-hooks"><dl> | |
<dt class="hdlist1"> | |
How do I use hooks to prevent users from making certain changes? | |
</dt> | |
<dd> | |
<p> | |
The only safe place to make these changes is on the remote repository | |
(i.e., the Git server), usually in the <code>pre-receive</code> hook or in a | |
continuous integration (CI) system. These are the locations in which | |
policy can be enforced effectively. | |
</p> | |
<div class="paragraph"><p>It’s common to try to use <code>pre-commit</code> hooks (or, for commit messages, | |
<code>commit-msg</code> hooks) to check these things, which is great if you’re working as a | |
solo developer and want the tooling to help you. However, using hooks on a | |
developer machine is not effective as a policy control because a user can bypass | |
these hooks with <code>--no-verify</code> without being noticed (among various other ways). | |
Git assumes that the user is in control of their local repositories and doesn’t | |
try to prevent this or tattle on the user.</p></div> | |
<div class="paragraph"><p>In addition, some advanced users find <code>pre-commit</code> hooks to be an impediment to | |
workflows that use temporary commits to stage work in progress or that create | |
fixup commits, so it’s better to push these kinds of checks to the server | |
anyway.</p></div> | |
</dd> | |
</dl></div> | |
</div> | |
</div> | |
<div class="sect1"> | |
<h2 id="_cross_platform_issues">Cross-Platform Issues</h2> | |
<div class="sectionbody"> | |
<div class="dlist" id="windows-text-binary"><dl> | |
<dt class="hdlist1"> | |
I’m on Windows and my text files are detected as binary. | |
</dt> | |
<dd> | |
<p> | |
Git works best when you store text files as UTF-8. Many programs on | |
Windows support UTF-8, but some do not and only use the little-endian | |
UTF-16 format, which Git detects as binary. If you can’t use UTF-8 with | |
your programs, you can specify a working tree encoding that indicates | |
which encoding your files should be checked out with, while still | |
storing these files as UTF-8 in the repository. This allows tools like | |
<a href="git-diff.html">git-diff(1)</a> to work as expected, while still allowing your tools | |
to work. | |
</p> | |
<div class="paragraph"><p>To do so, you can specify a <a href="gitattributes.html">gitattributes(5)</a> pattern with the | |
<code>working-tree-encoding</code> attribute. For example, the following pattern sets all | |
C files to use UTF-16LE-BOM, which is a common encoding on Windows:</p></div> | |
<div class="listingblock"> | |
<div class="content"> | |
<pre><code>*.c working-tree-encoding=UTF-16LE-BOM</code></pre> | |
</div></div> | |
<div class="paragraph"><p>You will need to run <code>git add --renormalize</code> to have this take effect. Note | |
that if you are making these changes on a project that is used across platforms, | |
you’ll probably want to make it in a per-user configuration file or in the one | |
in <code>$GIT_DIR/info/attributes</code>, since making it in a <code>.gitattributes</code> file in the | |
repository will apply to all users of the repository.</p></div> | |
<div class="paragraph"><p>See the following entry for information about normalizing line endings as well, | |
and see <a href="gitattributes.html">gitattributes(5)</a> for more information about attribute files.</p></div> | |
</dd> | |
<dt class="hdlist1"> | |
I’m on Windows and git diff shows my files as having a <code>^M</code> at the end. | |
</dt> | |
<dd> | |
<p> | |
By default, Git expects files to be stored with Unix line endings. As such, | |
the carriage return (<code>^M</code>) that is part of a Windows line ending is shown | |
because it is considered to be trailing whitespace. Git defaults to showing | |
trailing whitespace only on new lines, not existing ones. | |
</p> | |
<div class="paragraph" id="windows-diff-control-m"><p>You can store the files in the repository with Unix line endings and convert | |
them automatically to your platform’s line endings. To do that, set the | |
configuration option <code>core.eol</code> to <code>native</code> and see the following entry for | |
information about how to configure files as text or binary.</p></div> | |
<div class="paragraph"><p>You can also control this behavior with the <code>core.whitespace</code> setting if you | |
don’t wish to remove the carriage returns from your line endings.</p></div> | |
</dd> | |
<dt class="hdlist1"> | |
Why do I have a file that’s always modified? | |
</dt> | |
<dd> | |
<p> | |
Internally, Git always stores file names as sequences of bytes and doesn’t | |
perform any encoding or case folding. However, Windows and macOS by default | |
both perform case folding on file names. As a result, it’s possible to end up | |
with multiple files or directories whose names differ only in case. Git can | |
handle this just fine, but the file system can store only one of these files, | |
so when Git reads the other file to see its contents, it looks modified. | |
</p> | |
<div class="paragraph" id="always-modified-files-case"><p>It’s best to remove one of the files such that you only have one file. You can | |
do this with commands like the following (assuming two files <code>AFile.txt</code> and | |
<code>afile.txt</code>) on an otherwise clean working tree:</p></div> | |
<div class="listingblock"> | |
<div class="content"> | |
<pre><code>$ git rm --cached AFile.txt | |
$ git commit -m 'Remove files conflicting in case' | |
$ git checkout .</code></pre> | |
</div></div> | |
<div class="paragraph"><p>This avoids touching the disk, but removes the additional file. Your project | |
may prefer to adopt a naming convention, such as all-lowercase names, to avoid | |
this problem from occurring again; such a convention can be checked using a | |
<code>pre-receive</code> hook or as part of a continuous integration (CI) system.</p></div> | |
<div class="paragraph"><p>It is also possible for perpetually modified files to occur on any platform if a | |
smudge or clean filter is in use on your system but a file was previously | |
committed without running the smudge or clean filter. To fix this, run the | |
following on an otherwise clean working tree:</p></div> | |
<div class="listingblock"> | |
<div class="content"> | |
<pre><code>$ git add --renormalize .</code></pre> | |
</div></div> | |
</dd> | |
<dt class="hdlist1"> | |
What’s the recommended way to store files in Git? | |
</dt> | |
<dd> | |
<p> | |
While Git can store and handle any file of any type, there are some | |
settings that work better than others. In general, we recommend that | |
text files be stored in UTF-8 without a byte-order mark (BOM) with LF | |
(Unix-style) endings. We also recommend the use of UTF-8 (again, | |
without BOM) in commit messages. These are the settings that work best | |
across platforms and with tools such as <code>git diff</code> and <code>git merge</code>. | |
</p> | |
<div class="paragraph" id="recommended-storage-settings"><p>Additionally, if you have a choice between storage formats that are text based | |
or non-text based, we recommend storing files in the text format and, if | |
necessary, transforming them into the other format. For example, a text-based | |
SQL dump with one record per line will work much better for diffing and merging | |
than an actual database file. Similarly, text-based formats such as Markdown | |
and AsciiDoc will work better than binary formats such as Microsoft Word and | |
PDF.</p></div> | |
<div class="paragraph"><p>Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or | |
build products in the repository is generally not recommended. Dependencies and | |
build products are best stored on an artifact or package server with only | |
references, URLs, and hashes stored in the repository.</p></div> | |
<div class="paragraph"><p>We also recommend setting a <a href="gitattributes.html">gitattributes(5)</a> file to explicitly mark | |
which files are text and which are binary. If you want Git to guess, you can | |
set the attribute <code>text=auto</code>. For example, the following might be appropriate | |
in some projects:</p></div> | |
<div class="listingblock"> | |
<div class="content"> | |
<pre><code># By default, guess. | |
* text=auto | |
# Mark all C files as text. | |
*.c text | |
# Mark all JPEG files as binary. | |
*.jpg binary</code></pre> | |
</div></div> | |
<div class="paragraph"><p>These settings help tools pick the right format for output such as patches and | |
result in files being checked out in the appropriate line ending for the | |
platform.</p></div> | |
</dd> | |
</dl></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 | |
2021-09-01 16:44:20 PDT | |
</div> | |
</div> | |
</body> | |
</html> |