1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
|
<?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">
/*<+'])');
// 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>
|
