1168 lines
62 KiB
HTML
1168 lines
62 KiB
HTML
<!DOCTYPE html>
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
|
|
<head>
|
|
<meta charset="UTF-8"/>
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
|
|
<meta name="generator" content="Asciidoctor 2.0.23"/>
|
|
<title>gitfaq(7)</title>
|
|
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"/>
|
|
<style>
|
|
/*! Asciidoctor default stylesheet | MIT License | https://asciidoctor.org */
|
|
/* Uncomment the following line when using as a custom stylesheet */
|
|
/* @import "https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"; */
|
|
html{font-family:sans-serif;-webkit-text-size-adjust:100%}
|
|
a{background:none}
|
|
a:focus{outline:thin dotted}
|
|
a:active,a:hover{outline:0}
|
|
h1{font-size:2em;margin:.67em 0}
|
|
b,strong{font-weight:bold}
|
|
abbr{font-size:.9em}
|
|
abbr[title]{cursor:help;border-bottom:1px dotted #dddddf;text-decoration:none}
|
|
dfn{font-style:italic}
|
|
hr{height:0}
|
|
mark{background:#ff0;color:#000}
|
|
code,kbd,pre,samp{font-family:monospace;font-size:1em}
|
|
pre{white-space:pre-wrap}
|
|
q{quotes:"\201C" "\201D" "\2018" "\2019"}
|
|
small{font-size:80%}
|
|
sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}
|
|
sup{top:-.5em}
|
|
sub{bottom:-.25em}
|
|
img{border:0}
|
|
svg:not(:root){overflow:hidden}
|
|
figure{margin:0}
|
|
audio,video{display:inline-block}
|
|
audio:not([controls]){display:none;height:0}
|
|
fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em}
|
|
legend{border:0;padding:0}
|
|
button,input,select,textarea{font-family:inherit;font-size:100%;margin:0}
|
|
button,input{line-height:normal}
|
|
button,select{text-transform:none}
|
|
button,html input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer}
|
|
button[disabled],html input[disabled]{cursor:default}
|
|
input[type=checkbox],input[type=radio]{padding:0}
|
|
button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0}
|
|
textarea{overflow:auto;vertical-align:top}
|
|
table{border-collapse:collapse;border-spacing:0}
|
|
*,::before,::after{box-sizing:border-box}
|
|
html,body{font-size:100%}
|
|
body{background:#fff;color:rgba(0,0,0,.8);padding:0;margin:0;font-family:"Noto Serif","DejaVu Serif",serif;line-height:1;position:relative;cursor:auto;-moz-tab-size:4;-o-tab-size:4;tab-size:4;word-wrap:anywhere;-moz-osx-font-smoothing:grayscale;-webkit-font-smoothing:antialiased}
|
|
a:hover{cursor:pointer}
|
|
img,object,embed{max-width:100%;height:auto}
|
|
object,embed{height:100%}
|
|
img{-ms-interpolation-mode:bicubic}
|
|
.left{float:left!important}
|
|
.right{float:right!important}
|
|
.text-left{text-align:left!important}
|
|
.text-right{text-align:right!important}
|
|
.text-center{text-align:center!important}
|
|
.text-justify{text-align:justify!important}
|
|
.hide{display:none}
|
|
img,object,svg{display:inline-block;vertical-align:middle}
|
|
textarea{height:auto;min-height:50px}
|
|
select{width:100%}
|
|
.subheader,.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{line-height:1.45;color:#7a2518;font-weight:400;margin-top:0;margin-bottom:.25em}
|
|
div,dl,dt,dd,ul,ol,li,h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6,pre,form,p,blockquote,th,td{margin:0;padding:0}
|
|
a{color:#2156a5;text-decoration:underline;line-height:inherit}
|
|
a:hover,a:focus{color:#1d4b8f}
|
|
a img{border:0}
|
|
p{line-height:1.6;margin-bottom:1.25em;text-rendering:optimizeLegibility}
|
|
p aside{font-size:.875em;line-height:1.35;font-style:italic}
|
|
h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{font-family:"Open Sans","DejaVu Sans",sans-serif;font-weight:300;font-style:normal;color:#ba3925;text-rendering:optimizeLegibility;margin-top:1em;margin-bottom:.5em;line-height:1.0125em}
|
|
h1 small,h2 small,h3 small,#toctitle small,.sidebarblock>.content>.title small,h4 small,h5 small,h6 small{font-size:60%;color:#e99b8f;line-height:0}
|
|
h1{font-size:2.125em}
|
|
h2{font-size:1.6875em}
|
|
h3,#toctitle,.sidebarblock>.content>.title{font-size:1.375em}
|
|
h4,h5{font-size:1.125em}
|
|
h6{font-size:1em}
|
|
hr{border:solid #dddddf;border-width:1px 0 0;clear:both;margin:1.25em 0 1.1875em}
|
|
em,i{font-style:italic;line-height:inherit}
|
|
strong,b{font-weight:bold;line-height:inherit}
|
|
small{font-size:60%;line-height:inherit}
|
|
code{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;color:rgba(0,0,0,.9)}
|
|
ul,ol,dl{line-height:1.6;margin-bottom:1.25em;list-style-position:outside;font-family:inherit}
|
|
ul,ol{margin-left:1.5em}
|
|
ul li ul,ul li ol{margin-left:1.25em;margin-bottom:0}
|
|
ul.circle{list-style-type:circle}
|
|
ul.disc{list-style-type:disc}
|
|
ul.square{list-style-type:square}
|
|
ul.circle ul:not([class]),ul.disc ul:not([class]),ul.square ul:not([class]){list-style:inherit}
|
|
ol li ul,ol li ol{margin-left:1.25em;margin-bottom:0}
|
|
dl dt{margin-bottom:.3125em;font-weight:bold}
|
|
dl dd{margin-bottom:1.25em}
|
|
blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd}
|
|
blockquote,blockquote p{line-height:1.6;color:rgba(0,0,0,.85)}
|
|
@media screen and (min-width:768px){h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2}
|
|
h1{font-size:2.75em}
|
|
h2{font-size:2.3125em}
|
|
h3,#toctitle,.sidebarblock>.content>.title{font-size:1.6875em}
|
|
h4{font-size:1.4375em}}
|
|
table{background:#fff;margin-bottom:1.25em;border:1px solid #dedede;word-wrap:normal}
|
|
table thead,table tfoot{background:#f7f8f7}
|
|
table thead tr th,table thead tr td,table tfoot tr th,table tfoot tr td{padding:.5em .625em .625em;font-size:inherit;color:rgba(0,0,0,.8);text-align:left}
|
|
table tr th,table tr td{padding:.5625em .625em;font-size:inherit;color:rgba(0,0,0,.8)}
|
|
table tr.even,table tr.alt{background:#f8f8f7}
|
|
table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{line-height:1.6}
|
|
h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2;word-spacing:-.05em}
|
|
h1 strong,h2 strong,h3 strong,#toctitle strong,.sidebarblock>.content>.title strong,h4 strong,h5 strong,h6 strong{font-weight:400}
|
|
.center{margin-left:auto;margin-right:auto}
|
|
.stretch{width:100%}
|
|
.clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table}
|
|
.clearfix::after,.float-group::after{clear:both}
|
|
:not(pre).nobreak{word-wrap:normal}
|
|
:not(pre).nowrap{white-space:nowrap}
|
|
:not(pre).pre-wrap{white-space:pre-wrap}
|
|
:not(pre):not([class^=L])>code{font-size:.9375em;font-style:normal!important;letter-spacing:0;padding:.1em .5ex;word-spacing:-.15em;background:#f7f7f8;border-radius:4px;line-height:1.45;text-rendering:optimizeSpeed}
|
|
pre{color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;line-height:1.45;text-rendering:optimizeSpeed}
|
|
pre code,pre pre{color:inherit;font-size:inherit;line-height:inherit}
|
|
pre>code{display:block}
|
|
pre.nowrap,pre.nowrap pre{white-space:pre;word-wrap:normal}
|
|
em em{font-style:normal}
|
|
strong strong{font-weight:400}
|
|
.keyseq{color:rgba(51,51,51,.8)}
|
|
kbd{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;display:inline-block;color:rgba(0,0,0,.8);font-size:.65em;line-height:1.45;background:#f7f7f7;border:1px solid #ccc;border-radius:3px;box-shadow:0 1px 0 rgba(0,0,0,.2),inset 0 0 0 .1em #fff;margin:0 .15em;padding:.2em .5em;vertical-align:middle;position:relative;top:-.1em;white-space:nowrap}
|
|
.keyseq kbd:first-child{margin-left:0}
|
|
.keyseq kbd:last-child{margin-right:0}
|
|
.menuseq,.menuref{color:#000}
|
|
.menuseq b:not(.caret),.menuref{font-weight:inherit}
|
|
.menuseq{word-spacing:-.02em}
|
|
.menuseq b.caret{font-size:1.25em;line-height:.8}
|
|
.menuseq i.caret{font-weight:bold;text-align:center;width:.45em}
|
|
b.button::before,b.button::after{position:relative;top:-1px;font-weight:400}
|
|
b.button::before{content:"[";padding:0 3px 0 2px}
|
|
b.button::after{content:"]";padding:0 2px 0 3px}
|
|
p a>code:hover{color:rgba(0,0,0,.9)}
|
|
#header,#content,#footnotes,#footer{width:100%;margin:0 auto;max-width:62.5em;*zoom:1;position:relative;padding-left:.9375em;padding-right:.9375em}
|
|
#header::before,#header::after,#content::before,#content::after,#footnotes::before,#footnotes::after,#footer::before,#footer::after{content:" ";display:table}
|
|
#header::after,#content::after,#footnotes::after,#footer::after{clear:both}
|
|
#content{margin-top:1.25em}
|
|
#content::before{content:none}
|
|
#header>h1:first-child{color:rgba(0,0,0,.85);margin-top:2.25rem;margin-bottom:0}
|
|
#header>h1:first-child+#toc{margin-top:8px;border-top:1px solid #dddddf}
|
|
#header>h1:only-child{border-bottom:1px solid #dddddf;padding-bottom:8px}
|
|
#header .details{border-bottom:1px solid #dddddf;line-height:1.45;padding-top:.25em;padding-bottom:.25em;padding-left:.25em;color:rgba(0,0,0,.6);display:flex;flex-flow:row wrap}
|
|
#header .details span:first-child{margin-left:-.125em}
|
|
#header .details span.email a{color:rgba(0,0,0,.85)}
|
|
#header .details br{display:none}
|
|
#header .details br+span::before{content:"\00a0\2013\00a0"}
|
|
#header .details br+span.author::before{content:"\00a0\22c5\00a0";color:rgba(0,0,0,.85)}
|
|
#header .details br+span#revremark::before{content:"\00a0|\00a0"}
|
|
#header #revnumber{text-transform:capitalize}
|
|
#header #revnumber::after{content:"\00a0"}
|
|
#content>h1:first-child:not([class]){color:rgba(0,0,0,.85);border-bottom:1px solid #dddddf;padding-bottom:8px;margin-top:0;padding-top:1rem;margin-bottom:1.25rem}
|
|
#toc{border-bottom:1px solid #e7e7e9;padding-bottom:.5em}
|
|
#toc>ul{margin-left:.125em}
|
|
#toc ul.sectlevel0>li>a{font-style:italic}
|
|
#toc ul.sectlevel0 ul.sectlevel1{margin:.5em 0}
|
|
#toc ul{font-family:"Open Sans","DejaVu Sans",sans-serif;list-style-type:none}
|
|
#toc li{line-height:1.3334;margin-top:.3334em}
|
|
#toc a{text-decoration:none}
|
|
#toc a:active{text-decoration:underline}
|
|
#toctitle{color:#7a2518;font-size:1.2em}
|
|
@media screen and (min-width:768px){#toctitle{font-size:1.375em}
|
|
body.toc2{padding-left:15em;padding-right:0}
|
|
body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px}
|
|
#toc.toc2{margin-top:0!important;background:#f8f8f7;position:fixed;width:15em;left:0;top:0;border-right:1px solid #e7e7e9;border-top-width:0!important;border-bottom-width:0!important;z-index:1000;padding:1.25em 1em;height:100%;overflow:auto}
|
|
#toc.toc2 #toctitle{margin-top:0;margin-bottom:.8rem;font-size:1.2em}
|
|
#toc.toc2>ul{font-size:.9em;margin-bottom:0}
|
|
#toc.toc2 ul ul{margin-left:0;padding-left:1em}
|
|
#toc.toc2 ul.sectlevel0 ul.sectlevel1{padding-left:0;margin-top:.5em;margin-bottom:.5em}
|
|
body.toc2.toc-right{padding-left:0;padding-right:15em}
|
|
body.toc2.toc-right #toc.toc2{border-right-width:0;border-left:1px solid #e7e7e9;left:auto;right:0}}
|
|
@media screen and (min-width:1280px){body.toc2{padding-left:20em;padding-right:0}
|
|
#toc.toc2{width:20em}
|
|
#toc.toc2 #toctitle{font-size:1.375em}
|
|
#toc.toc2>ul{font-size:.95em}
|
|
#toc.toc2 ul ul{padding-left:1.25em}
|
|
body.toc2.toc-right{padding-left:0;padding-right:20em}}
|
|
#content #toc{border:1px solid #e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;border-radius:4px}
|
|
#content #toc>:first-child{margin-top:0}
|
|
#content #toc>:last-child{margin-bottom:0}
|
|
#footer{max-width:none;background:rgba(0,0,0,.8);padding:1.25em}
|
|
#footer-text{color:hsla(0,0%,100%,.8);line-height:1.44}
|
|
#content{margin-bottom:.625em}
|
|
.sect1{padding-bottom:.625em}
|
|
@media screen and (min-width:768px){#content{margin-bottom:1.25em}
|
|
.sect1{padding-bottom:1.25em}}
|
|
.sect1:last-child{padding-bottom:0}
|
|
.sect1+.sect1{border-top:1px solid #e7e7e9}
|
|
#content h1>a.anchor,h2>a.anchor,h3>a.anchor,#toctitle>a.anchor,.sidebarblock>.content>.title>a.anchor,h4>a.anchor,h5>a.anchor,h6>a.anchor{position:absolute;z-index:1001;width:1.5ex;margin-left:-1.5ex;display:block;text-decoration:none!important;visibility:hidden;text-align:center;font-weight:400}
|
|
#content h1>a.anchor::before,h2>a.anchor::before,h3>a.anchor::before,#toctitle>a.anchor::before,.sidebarblock>.content>.title>a.anchor::before,h4>a.anchor::before,h5>a.anchor::before,h6>a.anchor::before{content:"\00A7";font-size:.85em;display:block;padding-top:.1em}
|
|
#content h1:hover>a.anchor,#content h1>a.anchor:hover,h2:hover>a.anchor,h2>a.anchor:hover,h3:hover>a.anchor,#toctitle:hover>a.anchor,.sidebarblock>.content>.title:hover>a.anchor,h3>a.anchor:hover,#toctitle>a.anchor:hover,.sidebarblock>.content>.title>a.anchor:hover,h4:hover>a.anchor,h4>a.anchor:hover,h5:hover>a.anchor,h5>a.anchor:hover,h6:hover>a.anchor,h6>a.anchor:hover{visibility:visible}
|
|
#content h1>a.link,h2>a.link,h3>a.link,#toctitle>a.link,.sidebarblock>.content>.title>a.link,h4>a.link,h5>a.link,h6>a.link{color:#ba3925;text-decoration:none}
|
|
#content h1>a.link:hover,h2>a.link:hover,h3>a.link:hover,#toctitle>a.link:hover,.sidebarblock>.content>.title>a.link:hover,h4>a.link:hover,h5>a.link:hover,h6>a.link:hover{color:#a53221}
|
|
details,.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em}
|
|
details{margin-left:1.25rem}
|
|
details>summary{cursor:pointer;display:block;position:relative;line-height:1.6;margin-bottom:.625rem;outline:none;-webkit-tap-highlight-color:transparent}
|
|
details>summary::-webkit-details-marker{display:none}
|
|
details>summary::before{content:"";border:solid transparent;border-left:solid;border-width:.3em 0 .3em .5em;position:absolute;top:.5em;left:-1.25rem;transform:translateX(15%)}
|
|
details[open]>summary::before{border:solid transparent;border-top:solid;border-width:.5em .3em 0;transform:translateY(15%)}
|
|
details>summary::after{content:"";width:1.25rem;height:1em;position:absolute;top:.3em;left:-1.25rem}
|
|
.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{text-rendering:optimizeLegibility;text-align:left;font-family:"Noto Serif","DejaVu Serif",serif;font-size:1rem;font-style:italic}
|
|
table.tableblock.fit-content>caption.title{white-space:nowrap;width:0}
|
|
.paragraph.lead>p,#preamble>.sectionbody>[class=paragraph]:first-of-type p{font-size:1.21875em;line-height:1.6;color:rgba(0,0,0,.85)}
|
|
.admonitionblock>table{border-collapse:separate;border:0;background:none;width:100%}
|
|
.admonitionblock>table td.icon{text-align:center;width:80px}
|
|
.admonitionblock>table td.icon img{max-width:none}
|
|
.admonitionblock>table td.icon .title{font-weight:bold;font-family:"Open Sans","DejaVu Sans",sans-serif;text-transform:uppercase}
|
|
.admonitionblock>table td.content{padding-left:1.125em;padding-right:1.25em;border-left:1px solid #dddddf;color:rgba(0,0,0,.6);word-wrap:anywhere}
|
|
.admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0}
|
|
.exampleblock>.content{border:1px solid #e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;border-radius:4px}
|
|
.sidebarblock{border:1px solid #dbdbd6;margin-bottom:1.25em;padding:1.25em;background:#f3f3f2;border-radius:4px}
|
|
.sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center}
|
|
.exampleblock>.content>:first-child,.sidebarblock>.content>:first-child{margin-top:0}
|
|
.exampleblock>.content>:last-child,.exampleblock>.content>:last-child>:last-child,.exampleblock>.content .olist>ol>li:last-child>:last-child,.exampleblock>.content .ulist>ul>li:last-child>:last-child,.exampleblock>.content .qlist>ol>li:last-child>:last-child,.sidebarblock>.content>:last-child,.sidebarblock>.content>:last-child>:last-child,.sidebarblock>.content .olist>ol>li:last-child>:last-child,.sidebarblock>.content .ulist>ul>li:last-child>:last-child,.sidebarblock>.content .qlist>ol>li:last-child>:last-child{margin-bottom:0}
|
|
.literalblock pre,.listingblock>.content>pre{border-radius:4px;overflow-x:auto;padding:1em;font-size:.8125em}
|
|
@media screen and (min-width:768px){.literalblock pre,.listingblock>.content>pre{font-size:.90625em}}
|
|
@media screen and (min-width:1280px){.literalblock pre,.listingblock>.content>pre{font-size:1em}}
|
|
.literalblock pre,.listingblock>.content>pre:not(.highlight),.listingblock>.content>pre[class=highlight],.listingblock>.content>pre[class^="highlight "]{background:#f7f7f8}
|
|
.literalblock.output pre{color:#f7f7f8;background:rgba(0,0,0,.9)}
|
|
.listingblock>.content{position:relative}
|
|
.listingblock code[data-lang]::before{display:none;content:attr(data-lang);position:absolute;font-size:.75em;top:.425rem;right:.5rem;line-height:1;text-transform:uppercase;color:inherit;opacity:.5}
|
|
.listingblock:hover code[data-lang]::before{display:block}
|
|
.listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:inherit;opacity:.5}
|
|
.listingblock.terminal pre .command:not([data-prompt])::before{content:"$"}
|
|
.listingblock pre.highlightjs{padding:0}
|
|
.listingblock pre.highlightjs>code{padding:1em;border-radius:4px}
|
|
.listingblock pre.prettyprint{border-width:0}
|
|
.prettyprint{background:#f7f7f8}
|
|
pre.prettyprint .linenums{line-height:1.45;margin-left:2em}
|
|
pre.prettyprint li{background:none;list-style-type:inherit;padding-left:0}
|
|
pre.prettyprint li code[data-lang]::before{opacity:1}
|
|
pre.prettyprint li:not(:first-child) code[data-lang]::before{display:none}
|
|
table.linenotable{border-collapse:separate;border:0;margin-bottom:0;background:none}
|
|
table.linenotable td[class]{color:inherit;vertical-align:top;padding:0;line-height:inherit;white-space:normal}
|
|
table.linenotable td.code{padding-left:.75em}
|
|
table.linenotable td.linenos,pre.pygments .linenos{border-right:1px solid;opacity:.35;padding-right:.5em;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none}
|
|
pre.pygments span.linenos{display:inline-block;margin-right:.75em}
|
|
.quoteblock{margin:0 1em 1.25em 1.5em;display:table}
|
|
.quoteblock:not(.excerpt)>.title{margin-left:-1.5em;margin-bottom:.75em}
|
|
.quoteblock blockquote,.quoteblock p{color:rgba(0,0,0,.85);font-size:1.15rem;line-height:1.75;word-spacing:.1em;letter-spacing:0;font-style:italic;text-align:justify}
|
|
.quoteblock blockquote{margin:0;padding:0;border:0}
|
|
.quoteblock blockquote::before{content:"\201c";float:left;font-size:2.75em;font-weight:bold;line-height:.6em;margin-left:-.6em;color:#7a2518;text-shadow:0 1px 2px rgba(0,0,0,.1)}
|
|
.quoteblock blockquote>.paragraph:last-child p{margin-bottom:0}
|
|
.quoteblock .attribution{margin-top:.75em;margin-right:.5ex;text-align:right}
|
|
.verseblock{margin:0 1em 1.25em}
|
|
.verseblock pre{font-family:"Open Sans","DejaVu Sans",sans-serif;font-size:1.15rem;color:rgba(0,0,0,.85);font-weight:300;text-rendering:optimizeLegibility}
|
|
.verseblock pre strong{font-weight:400}
|
|
.verseblock .attribution{margin-top:1.25rem;margin-left:.5ex}
|
|
.quoteblock .attribution,.verseblock .attribution{font-size:.9375em;line-height:1.45;font-style:italic}
|
|
.quoteblock .attribution br,.verseblock .attribution br{display:none}
|
|
.quoteblock .attribution cite,.verseblock .attribution cite{display:block;letter-spacing:-.025em;color:rgba(0,0,0,.6)}
|
|
.quoteblock.abstract blockquote::before,.quoteblock.excerpt blockquote::before,.quoteblock .quoteblock blockquote::before{display:none}
|
|
.quoteblock.abstract blockquote,.quoteblock.abstract p,.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{line-height:1.6;word-spacing:0}
|
|
.quoteblock.abstract{margin:0 1em 1.25em;display:block}
|
|
.quoteblock.abstract>.title{margin:0 0 .375em;font-size:1.15em;text-align:center}
|
|
.quoteblock.excerpt>blockquote,.quoteblock .quoteblock{padding:0 0 .25em 1em;border-left:.25em solid #dddddf}
|
|
.quoteblock.excerpt,.quoteblock .quoteblock{margin-left:0}
|
|
.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{color:inherit;font-size:1.0625rem}
|
|
.quoteblock.excerpt .attribution,.quoteblock .quoteblock .attribution{color:inherit;font-size:.85rem;text-align:left;margin-right:0}
|
|
p.tableblock:last-child{margin-bottom:0}
|
|
td.tableblock>.content{margin-bottom:1.25em;word-wrap:anywhere}
|
|
td.tableblock>.content>:last-child{margin-bottom:-1.25em}
|
|
table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede}
|
|
table.grid-all>*>tr>*{border-width:1px}
|
|
table.grid-cols>*>tr>*{border-width:0 1px}
|
|
table.grid-rows>*>tr>*{border-width:1px 0}
|
|
table.frame-all{border-width:1px}
|
|
table.frame-ends{border-width:1px 0}
|
|
table.frame-sides{border-width:0 1px}
|
|
table.frame-none>colgroup+*>:first-child>*,table.frame-sides>colgroup+*>:first-child>*{border-top-width:0}
|
|
table.frame-none>:last-child>:last-child>*,table.frame-sides>:last-child>:last-child>*{border-bottom-width:0}
|
|
table.frame-none>*>tr>:first-child,table.frame-ends>*>tr>:first-child{border-left-width:0}
|
|
table.frame-none>*>tr>:last-child,table.frame-ends>*>tr>:last-child{border-right-width:0}
|
|
table.stripes-all>*>tr,table.stripes-odd>*>tr:nth-of-type(odd),table.stripes-even>*>tr:nth-of-type(even),table.stripes-hover>*>tr:hover{background:#f8f8f7}
|
|
th.halign-left,td.halign-left{text-align:left}
|
|
th.halign-right,td.halign-right{text-align:right}
|
|
th.halign-center,td.halign-center{text-align:center}
|
|
th.valign-top,td.valign-top{vertical-align:top}
|
|
th.valign-bottom,td.valign-bottom{vertical-align:bottom}
|
|
th.valign-middle,td.valign-middle{vertical-align:middle}
|
|
table thead th,table tfoot th{font-weight:bold}
|
|
tbody tr th{background:#f7f8f7}
|
|
tbody tr th,tbody tr th p,tfoot tr th,tfoot tr th p{color:rgba(0,0,0,.8);font-weight:bold}
|
|
p.tableblock>code:only-child{background:none;padding:0}
|
|
p.tableblock{font-size:1em}
|
|
ol{margin-left:1.75em}
|
|
ul li ol{margin-left:1.5em}
|
|
dl dd{margin-left:1.125em}
|
|
dl dd:last-child,dl dd:last-child>:last-child{margin-bottom:0}
|
|
li p,ul dd,ol dd,.olist .olist,.ulist .ulist,.ulist .olist,.olist .ulist{margin-bottom:.625em}
|
|
ul.checklist,ul.none,ol.none,ul.no-bullet,ol.no-bullet,ol.unnumbered,ul.unstyled,ol.unstyled{list-style-type:none}
|
|
ul.no-bullet,ol.no-bullet,ol.unnumbered{margin-left:.625em}
|
|
ul.unstyled,ol.unstyled{margin-left:0}
|
|
li>p:empty:only-child::before{content:"";display:inline-block}
|
|
ul.checklist>li>p:first-child{margin-left:-1em}
|
|
ul.checklist>li>p:first-child>.fa-square-o:first-child,ul.checklist>li>p:first-child>.fa-check-square-o:first-child{width:1.25em;font-size:.8em;position:relative;bottom:.125em}
|
|
ul.checklist>li>p:first-child>input[type=checkbox]:first-child{margin-right:.25em}
|
|
ul.inline{display:flex;flex-flow:row wrap;list-style:none;margin:0 0 .625em -1.25em}
|
|
ul.inline>li{margin-left:1.25em}
|
|
.unstyled dl dt{font-weight:400;font-style:normal}
|
|
ol.arabic{list-style-type:decimal}
|
|
ol.decimal{list-style-type:decimal-leading-zero}
|
|
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}
|
|
ol.lowergreek{list-style-type:lower-greek}
|
|
.hdlist>table,.colist>table{border:0;background:none}
|
|
.hdlist>table>tbody>tr,.colist>table>tbody>tr{background:none}
|
|
td.hdlist1,td.hdlist2{vertical-align:top;padding:0 .625em}
|
|
td.hdlist1{font-weight:bold;padding-bottom:1.25em}
|
|
td.hdlist2{word-wrap:anywhere}
|
|
.literalblock+.colist,.listingblock+.colist{margin-top:-.5em}
|
|
.colist td:not([class]):first-child{padding:.4em .75em 0;line-height:1;vertical-align:top}
|
|
.colist td:not([class]):first-child img{max-width:none}
|
|
.colist td:not([class]):last-child{padding:.25em 0}
|
|
.thumb,.th{line-height:0;display:inline-block;border:4px solid #fff;box-shadow:0 0 0 1px #ddd}
|
|
.imageblock.left{margin:.25em .625em 1.25em 0}
|
|
.imageblock.right{margin:.25em 0 1.25em .625em}
|
|
.imageblock>.title{margin-bottom:0}
|
|
.imageblock.thumb,.imageblock.th{border-width:6px}
|
|
.imageblock.thumb>.title,.imageblock.th>.title{padding:0 .125em}
|
|
.image.left,.image.right{margin-top:.25em;margin-bottom:.25em;display:inline-block;line-height:0}
|
|
.image.left{margin-right:.625em}
|
|
.image.right{margin-left:.625em}
|
|
a.image{text-decoration:none;display:inline-block}
|
|
a.image object{pointer-events:none}
|
|
sup.footnote,sup.footnoteref{font-size:.875em;position:static;vertical-align:super}
|
|
sup.footnote a,sup.footnoteref a{text-decoration:none}
|
|
sup.footnote a:active,sup.footnoteref a:active,#footnotes .footnote a:first-of-type:active{text-decoration:underline}
|
|
#footnotes{padding-top:.75em;padding-bottom:.75em;margin-bottom:.625em}
|
|
#footnotes hr{width:20%;min-width:6.25em;margin:-.25em 0 .75em;border-width:1px 0 0}
|
|
#footnotes .footnote{padding:0 .375em 0 .225em;line-height:1.3334;font-size:.875em;margin-left:1.2em;margin-bottom:.2em}
|
|
#footnotes .footnote a:first-of-type{font-weight:bold;text-decoration:none;margin-left:-1.05em}
|
|
#footnotes .footnote:last-of-type{margin-bottom:0}
|
|
#content #footnotes{margin-top:-.625em;margin-bottom:0;padding:.75em 0}
|
|
div.unbreakable{page-break-inside:avoid}
|
|
.big{font-size:larger}
|
|
.small{font-size:smaller}
|
|
.underline{text-decoration:underline}
|
|
.overline{text-decoration:overline}
|
|
.line-through{text-decoration:line-through}
|
|
.aqua{color:#00bfbf}
|
|
.aqua-background{background:#00fafa}
|
|
.black{color:#000}
|
|
.black-background{background:#000}
|
|
.blue{color:#0000bf}
|
|
.blue-background{background:#0000fa}
|
|
.fuchsia{color:#bf00bf}
|
|
.fuchsia-background{background:#fa00fa}
|
|
.gray{color:#606060}
|
|
.gray-background{background:#7d7d7d}
|
|
.green{color:#006000}
|
|
.green-background{background:#007d00}
|
|
.lime{color:#00bf00}
|
|
.lime-background{background:#00fa00}
|
|
.maroon{color:#600000}
|
|
.maroon-background{background:#7d0000}
|
|
.navy{color:#000060}
|
|
.navy-background{background:#00007d}
|
|
.olive{color:#606000}
|
|
.olive-background{background:#7d7d00}
|
|
.purple{color:#600060}
|
|
.purple-background{background:#7d007d}
|
|
.red{color:#bf0000}
|
|
.red-background{background:#fa0000}
|
|
.silver{color:#909090}
|
|
.silver-background{background:#bcbcbc}
|
|
.teal{color:#006060}
|
|
.teal-background{background:#007d7d}
|
|
.white{color:#bfbfbf}
|
|
.white-background{background:#fafafa}
|
|
.yellow{color:#bfbf00}
|
|
.yellow-background{background:#fafa00}
|
|
span.icon>.fa{cursor:default}
|
|
a span.icon>.fa{cursor:inherit}
|
|
.admonitionblock td.icon [class^="fa icon-"]{font-size:2.5em;text-shadow:1px 1px 2px rgba(0,0,0,.5);cursor:default}
|
|
.admonitionblock td.icon .icon-note::before{content:"\f05a";color:#19407c}
|
|
.admonitionblock td.icon .icon-tip::before{content:"\f0eb";text-shadow:1px 1px 2px rgba(155,155,0,.8);color:#111}
|
|
.admonitionblock td.icon .icon-warning::before{content:"\f071";color:#bf6900}
|
|
.admonitionblock td.icon .icon-caution::before{content:"\f06d";color:#bf3400}
|
|
.admonitionblock td.icon .icon-important::before{content:"\f06a";color:#bf0000}
|
|
.conum[data-value]{display:inline-block;color:#fff!important;background:rgba(0,0,0,.8);border-radius:50%;text-align:center;font-size:.75em;width:1.67em;height:1.67em;line-height:1.67em;font-family:"Open Sans","DejaVu Sans",sans-serif;font-style:normal;font-weight:bold}
|
|
.conum[data-value] *{color:#fff!important}
|
|
.conum[data-value]+b{display:none}
|
|
.conum[data-value]::after{content:attr(data-value)}
|
|
pre .conum[data-value]{position:relative;top:-.125em}
|
|
b.conum *{color:inherit!important}
|
|
.conum:not([data-value]):empty{display:none}
|
|
dt,th.tableblock,td.content,div.footnote{text-rendering:optimizeLegibility}
|
|
h1,h2,p,td.content,span.alt,summary{letter-spacing:-.01em}
|
|
p strong,td.content strong,div.footnote strong{letter-spacing:-.005em}
|
|
p,blockquote,dt,td.content,td.hdlist1,span.alt,summary{font-size:1.0625rem}
|
|
p{margin-bottom:1.25rem}
|
|
.sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em}
|
|
.exampleblock>.content{background:#fffef7;border-color:#e0e0dc;box-shadow:0 1px 4px #e0e0dc}
|
|
.print-only{display:none!important}
|
|
@page{margin:1.25cm .75cm}
|
|
@media print{*{box-shadow:none!important;text-shadow:none!important}
|
|
html{font-size:80%}
|
|
a{color:inherit!important;text-decoration:underline!important}
|
|
a.bare,a[href^="#"],a[href^="mailto:"]{text-decoration:none!important}
|
|
a[href^="http:"]:not(.bare)::after,a[href^="https:"]:not(.bare)::after{content:"(" attr(href) ")";display:inline-block;font-size:.875em;padding-left:.25em}
|
|
abbr[title]{border-bottom:1px dotted}
|
|
abbr[title]::after{content:" (" attr(title) ")"}
|
|
pre,blockquote,tr,img,object,svg{page-break-inside:avoid}
|
|
thead{display:table-header-group}
|
|
svg{max-width:100%}
|
|
p,blockquote,dt,td.content{font-size:1em;orphans:3;widows:3}
|
|
h2,h3,#toctitle,.sidebarblock>.content>.title{page-break-after:avoid}
|
|
#header,#content,#footnotes,#footer{max-width:none}
|
|
#toc,.sidebarblock,.exampleblock>.content{background:none!important}
|
|
#toc{border-bottom:1px solid #dddddf!important;padding-bottom:0!important}
|
|
body.book #header{text-align:center}
|
|
body.book #header>h1:first-child{border:0!important;margin:2.5em 0 1em}
|
|
body.book #header .details{border:0!important;display:block;padding:0!important}
|
|
body.book #header .details span:first-child{margin-left:0!important}
|
|
body.book #header .details br{display:block}
|
|
body.book #header .details br+span::before{content:none!important}
|
|
body.book #toc{border:0!important;text-align:left!important;padding:0!important;margin:0!important}
|
|
body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-break-before:always}
|
|
.listingblock code[data-lang]::before{display:block}
|
|
#footer{padding:0 .9375em}
|
|
.hide-on-print{display:none!important}
|
|
.print-only{display:block!important}
|
|
.hide-for-print{display:none!important}
|
|
.show-for-print{display:inherit!important}}
|
|
@media amzn-kf8,print{#header>h1:first-child{margin-top:1.25rem}
|
|
.sect1{padding:0!important}
|
|
.sect1+.sect1{border:0}
|
|
#footer{background:none}
|
|
#footer-text{color:rgba(0,0,0,.6);font-size:.9em}}
|
|
@media amzn-kf8{#header,#content,#footnotes,#footer{padding:0}}
|
|
</style>
|
|
<style>
|
|
pre>code {
|
|
display: inline;
|
|
}
|
|
</style>
|
|
</head>
|
|
<body class="manpage">
|
|
<div id="header">
|
|
<h1>gitfaq(7) Manual Page</h1>
|
|
<h2 id="_name">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 id="user-name" class="dlist">
|
|
<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>
|
|
</dl>
|
|
</div>
|
|
<div id="http-postbuffer" class="dlist">
|
|
<dl>
|
|
<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">
|
|
<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>
|
|
</dl>
|
|
</div>
|
|
<div id="configure-editor" class="dlist">
|
|
<dl>
|
|
<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">
|
|
<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>export VISUAL=nano</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 "C:\Program <code>Files</code>\Vim\gvim.<code>exe</code>" <code>--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 id="http-credentials" class="dlist">
|
|
<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>
|
|
</dl>
|
|
</div>
|
|
<div id="http-credentials-environment" class="dlist">
|
|
<dl>
|
|
<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">
|
|
<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>$ git config credential.helper \
|
|
'!f() { echo username=author; echo "password=$GIT_TOKEN"; };f'</pre>
|
|
</div>
|
|
</div>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
<div id="http-reset-credentials" class="dlist">
|
|
<dl>
|
|
<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">
|
|
<div class="content">
|
|
<pre>$ echo url=https://author@git.example.org | git credential reject</pre>
|
|
</div>
|
|
</div>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
<div id="multiple-accounts-http" class="dlist">
|
|
<dl>
|
|
<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" class="bare">https://author@git.example.org/org1/project1.git</a> and
|
|
<a href="https://committer@git.example.org/org2/project2.git" class="bare">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</code> <code>remote</code> <code>set-url</code>
|
|
<code>origin</code> <code>https://author@git.example.org/org1/project1.git</code> (see
|
|
<a href="git-remote.html">git-remote(1)</a> for details).</p>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
<div id="multiple-accounts-ssh" class="dlist">
|
|
<dl>
|
|
<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</code> <code>-t</code> <code>ed25519</code> <code>-f</code> <code>~/.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">
|
|
<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># 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</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</code> <code>remote</code> <code>set-url</code>
|
|
<code>git@example_author:org1/project1.git</code>).</p>
|
|
</div>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_transfers">Transfers</h2>
|
|
<div class="sectionbody">
|
|
<div id="sync-working-tree" class="dlist">
|
|
<dl>
|
|
<dt class="hdlist1">How do I sync a working tree across systems?</dt>
|
|
<dd>
|
|
<p>First, decide whether you want to do this at all. Git works best when you
|
|
push or pull your work using the typical <code>git</code> <code>push</code> and <code>git</code> <code>fetch</code> commands
|
|
and isn’t designed to share a working tree across systems. This is
|
|
potentially risky and in some cases can cause repository corruption or data
|
|
loss.</p>
|
|
<div class="paragraph">
|
|
<p>Usually, doing so will cause <code>git</code> <code>status</code> to need to re-read every file in the
|
|
working tree. Additionally, Git’s security model does not permit sharing a
|
|
working tree across untrusted users, so it is only safe to sync a working tree
|
|
if it will only be used by a single user across all machines.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>It is important not to use a cloud syncing service to sync any portion of a Git
|
|
repository, since this can cause corruption, such as missing objects, changed
|
|
or added files, broken refs, and a wide variety of other problems. These
|
|
services tend to sync file by file on a continuous basis and don’t understand
|
|
the structure of a Git repository. This is especially bad if they sync the
|
|
repository in the middle of it being updated, since that is very likely to
|
|
cause incomplete or partial updates and therefore data loss.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>An example of the kind of corruption that can occur is conflicts over the state
|
|
of refs, such that both sides end up with different commits on a branch that
|
|
the other doesn’t have. This can result in important objects becoming
|
|
unreferenced and possibly pruned by <code>git</code> <code>gc</code>, causing data loss.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Therefore, it’s better to push your work to either the other system or a central
|
|
server using the normal push and pull mechanism. However, this doesn’t always
|
|
preserve important data, like stashes, so some people prefer to share a working
|
|
tree across systems.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>If you do this, the recommended approach is to use <code>rsync</code> <code>-a</code> <code>--delete-after</code>
|
|
(ideally with an encrypted connection such as with <code>ssh</code>) on the root of
|
|
repository. You should ensure several things when you do this:</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>If you have additional worktrees or a separate Git directory, they must be
|
|
synced at the same time as the main working tree and repository.</p>
|
|
</li>
|
|
<li>
|
|
<p>You are comfortable with the destination directory being an exact copy of the
|
|
source directory, <em>deleting any data that is already there</em>.</p>
|
|
</li>
|
|
<li>
|
|
<p>The repository (including all worktrees and the Git directory) is in a
|
|
quiescent state for the duration of the transfer (that is, no operations of
|
|
any sort are taking place on it, including background operations like <code>git</code>
|
|
<code>gc</code> and operations invoked by your editor).</p>
|
|
<div class="paragraph">
|
|
<p>Be aware that even with these recommendations, syncing in this way has some risk
|
|
since it bypasses Git’s normal integrity checking for repositories, so having
|
|
backups is advised. You may also wish to do a <code>git</code> <code>fsck</code> to verify the
|
|
integrity of your data on the destination system after syncing.</p>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_common_issues">Common Issues</h2>
|
|
<div class="sectionbody">
|
|
<div id="last-commit-amend" class="dlist">
|
|
<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</code> <code>add</code>
|
|
<em><file></em> or <code>git</code> <code>rm</code> <em><file></em>, as appropriate, to stage it, and then <code>git</code>
|
|
<code>commit</code> <code>--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</code>
|
|
<code>commit</code> in addition, or just save and quit when your editor opens.</p>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
<div id="undo-previous-change" class="dlist">
|
|
<dl>
|
|
<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</code> <code>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>
|
|
</dl>
|
|
</div>
|
|
<div id="ignore-tracked-files" class="dlist">
|
|
<dl>
|
|
<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">
|
|
<p>It’s tempting to try to use certain features of <code>git</code> <code>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>
|
|
</dl>
|
|
</div>
|
|
<div id="files-in-gitignore-are-tracked" class="dlist">
|
|
<dl>
|
|
<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</code> <code>rm</code> <code>--cached</code> <file/pattern>
|
|
and add a pattern to .<code>gitignore</code> that matches the <file>.
|
|
See <a href="gitignore.html">gitignore(5)</a> for details.</p>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
<div id="fetching-and-pulling" class="dlist">
|
|
<dl>
|
|
<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 id="proxy" class="dlist">
|
|
<dl>
|
|
<dt class="hdlist1">Can I use a proxy with Git?</dt>
|
|
<dd>
|
|
<p>Yes, Git supports the use of proxies. Git honors the standard <code>http_proxy</code>,
|
|
<code>https_proxy</code>, and <code>no_proxy</code> environment variables commonly used on Unix, and
|
|
it also can be configured with <code>http.proxy</code> and similar options for HTTPS (see
|
|
<a href="git-config.html">git-config(1)</a>). The <code>http.proxy</code> and related options can be
|
|
customized on a per-URL pattern basis. In addition, Git can in theory
|
|
function normally with transparent proxies that exist on the network.</p>
|
|
<div class="paragraph">
|
|
<p>For SSH, Git can support a proxy using OpenSSH’s <code>ProxyCommand</code>. Commonly used
|
|
tools include <code>netcat</code> and <code>socat</code>. However, they must be configured not to
|
|
exit when seeing EOF on standard input, which usually means that <code>netcat</code> will
|
|
require <code>-q</code> and <code>socat</code> will require a timeout with something like <code>-t</code> <code>10</code>.
|
|
This is required because the way the Git SSH server knows that no more requests
|
|
will be made is an EOF on standard input, but when that happens, the server may
|
|
not have yet processed the final request, so dropping the connection at that
|
|
point would interrupt that request.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>An example configuration entry in <code>~/.ssh/config</code> with an HTTP proxy might look
|
|
like this:</p>
|
|
</div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre>Host git.example.org
|
|
User git
|
|
ProxyCommand socat -t 10 - PROXY:proxy.example.org:%h:%p,proxyport=8080</pre>
|
|
</div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Note that in all cases, for Git to work properly, the proxy must be completely
|
|
transparent. The proxy cannot modify, tamper with, or buffer the connection in
|
|
any way, or Git will almost certainly fail to work. Note that many proxies,
|
|
including many TLS middleboxes, Windows antivirus and firewall programs other
|
|
than Windows Defender and Windows Firewall, and filtering proxies fail to meet
|
|
this standard, and as a result end up breaking Git. Because of the many
|
|
reports of problems and their poor security history, we recommend against the
|
|
use of these classes of software and devices.</p>
|
|
</div>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_merging_and_rebasing">Merging and Rebasing</h2>
|
|
<div class="sectionbody">
|
|
<div id="long-running-squash-merge" class="dlist">
|
|
<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</code> <code>log</code> output, with a GUI, or when using the ... 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 ... notation in <code>git</code>
|
|
<code>diff</code>, <code>git</code> <code>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>
|
|
</dl>
|
|
</div>
|
|
<div id="merge-two-revert-one" class="dlist">
|
|
<dl>
|
|
<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">
|
|
<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 id="restrict-with-hooks" class="dlist">
|
|
<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 id="windows-text-binary" class="dlist">
|
|
<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>*.c working-tree-encoding=UTF-16LE-BOM</pre>
|
|
</div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>You will need to run <code>git</code> <code>add</code> <code>--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>
|
|
</dl>
|
|
</div>
|
|
<div id="windows-diff-control-m" class="dlist">
|
|
<dl>
|
|
<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">
|
|
<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
|
|
<a href="#recommended-storage-settings">the question on recommended storage settings</a>
|
|
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>
|
|
</dl>
|
|
</div>
|
|
<div id="always-modified-files-case" class="dlist">
|
|
<dl>
|
|
<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">
|
|
<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>$ git rm --cached AFile.txt
|
|
$ git commit -m 'Remove files conflicting in case'
|
|
$ git checkout .</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>$ git add --renormalize .</pre>
|
|
</div>
|
|
</div>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
<div id="recommended-storage-settings" class="dlist">
|
|
<dl>
|
|
<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</code> <code>diff</code> and <code>git</code> <code>merge</code>.</p>
|
|
<div class="paragraph">
|
|
<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>.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>With text files, Git will generally ensure that LF endings are used in the
|
|
repository. The <code>core.autocrlf</code> and <code>core.eol</code> configuration variables specify
|
|
what line-ending convention is followed when any text file is checked out. You
|
|
can also use the <code>eol</code> attribute (e.g., <code>eol=crlf</code>) to override which files get
|
|
what line-ending treatment.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>For example, generally shell files must have LF endings and batch files must
|
|
have CRLF endings, so the following might be appropriate in some projects:</p>
|
|
</div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre># By default, guess.
|
|
* text=auto
|
|
# Mark all C files as text.
|
|
*.c text
|
|
# Ensure all shell files have LF endings and all batch files have CRLF
|
|
# endings in the working tree and both have LF in the repo.
|
|
*.sh text eol=lf
|
|
*.bat text eol=crlf
|
|
# Mark all JPEG files as binary.
|
|
*.jpg binary</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="footer">
|
|
<div id="footer-text">
|
|
Last updated 2025-03-17 07:09:38 UTC
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |