-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpush default
2962 lines (2296 loc) · 167 KB
/
push default
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
GIT-CONFIG(1) Git Manual GIT-CONFIG(1)
NNAAMMEE
git-config - Get and set repository or global options
SSYYNNOOPPSSIISS
_g_i_t _c_o_n_f_i_g [<file-option>] [type] [-z|--null] name [value [value_regex]]
_g_i_t _c_o_n_f_i_g [<file-option>] [type] --add name value
_g_i_t _c_o_n_f_i_g [<file-option>] [type] --replace-all name value [value_regex]
_g_i_t _c_o_n_f_i_g [<file-option>] [type] [-z|--null] --get name [value_regex]
_g_i_t _c_o_n_f_i_g [<file-option>] [type] [-z|--null] --get-all name [value_regex]
_g_i_t _c_o_n_f_i_g [<file-option>] [type] [-z|--null] [--name-only] --get-regexp name_regex [value_regex]
_g_i_t _c_o_n_f_i_g [<file-option>] [type] [-z|--null] --get-urlmatch name URL
_g_i_t _c_o_n_f_i_g [<file-option>] --unset name [value_regex]
_g_i_t _c_o_n_f_i_g [<file-option>] --unset-all name [value_regex]
_g_i_t _c_o_n_f_i_g [<file-option>] --rename-section old_name new_name
_g_i_t _c_o_n_f_i_g [<file-option>] --remove-section name
_g_i_t _c_o_n_f_i_g [<file-option>] [-z|--null] [--name-only] -l | --list
_g_i_t _c_o_n_f_i_g [<file-option>] --get-color name [default]
_g_i_t _c_o_n_f_i_g [<file-option>] --get-colorbool name [stdout-is-tty]
_g_i_t _c_o_n_f_i_g [<file-option>] -e | --edit
DDEESSCCRRIIPPTTIIOONN
You can query/set/replace/unset options with this command. The name is actually the section
and the key separated by a dot, and the value will be escaped.
Multiple lines can be added to an option by using the _-_-_a_d_d option. If you want to update or
unset an option which can occur on multiple lines, a POSIX regexp value_regex needs to be
given. Only the existing values that match the regexp are updated or unset. If you want to
handle the lines that do nnoott match the regex, just prepend a single exclamation mark in
front (see also the section called “EXAMPLES”).
The type specifier can be either _-_-_i_n_t or _-_-_b_o_o_l, to make _g_i_t _c_o_n_f_i_g ensure that the
variable(s) are of the given type and convert the value to the canonical form (simple
decimal number for int, a "true" or "false" string for bool), or _-_-_p_a_t_h, which does some
path expansion (see _-_-_p_a_t_h below). If no type specifier is passed, no checks or
transformations are performed on the value.
When reading, the values are read from the system, global and repository local configuration
files by default, and options _-_-_s_y_s_t_e_m, _-_-_g_l_o_b_a_l, _-_-_l_o_c_a_l and _-_-_f_i_l_e _<_f_i_l_e_n_a_m_e_> can be used
to tell the command to read from only that location (see the section called “FILES”).
When writing, the new value is written to the repository local configuration file by
default, and options _-_-_s_y_s_t_e_m, _-_-_g_l_o_b_a_l, _-_-_f_i_l_e _<_f_i_l_e_n_a_m_e_> can be used to tell the command
to write to that location (you can say _-_-_l_o_c_a_l but that is the default).
This command will fail with non-zero status upon error. Some exit codes are:
1. The config file is invalid (ret=3),
2. can not write to the config file (ret=4),
3. no section or name was provided (ret=2),
4. the section or key is invalid (ret=1),
5. you try to unset an option which does not exist (ret=5),
6. you try to unset/set an option for which multiple lines match (ret=5), or
7. you try to use an invalid regexp (ret=6).
On success, the command returns the exit code 0.
OOPPTTIIOONNSS
--replace-all
Default behavior is to replace at most one line. This replaces all lines matching the
key (and optionally the value_regex).
--add
Adds a new line to the option without altering any existing values. This is the same as
providing _^_$ as the value_regex in --replace-all.
--get
Get the value for a given key (optionally filtered by a regex matching the value).
Returns error code 1 if the key was not found and the last value if multiple key values
were found.
--get-all
Like get, but does not fail if the number of values for the key is not exactly one.
--get-regexp
Like --get-all, but interprets the name as a regular expression and writes out the key
names. Regular expression matching is currently case-sensitive and done against a
canonicalized version of the key in which section and variable names are lowercased, but
subsection names are not.
--get-urlmatch name URL
When given a two-part name section.key, the value for section.<url>.key whose <url> part
matches the best to the given URL is returned (if no such key exists, the value for
section.key is used as a fallback). When given just the section as name, do so for all
the keys in the section and list them.
--global
For writing options: write to global ~/.gitconfig file rather than the repository
.git/config, write to $XDG_CONFIG_HOME/git/config file if this file exists and the
~/.gitconfig file doesn’t.
For reading options: read only from global ~/.gitconfig and from
$XDG_CONFIG_HOME/git/config rather than from all available files.
See also the section called “FILES”.
--system
For writing options: write to system-wide $(prefix)/etc/gitconfig rather than the
repository .git/config.
For reading options: read only from system-wide $(prefix)/etc/gitconfig rather than from
all available files.
See also the section called “FILES”.
--local
For writing options: write to the repository .git/config file. This is the default
behavior.
For reading options: read only from the repository .git/config rather than from all
available files.
See also the section called “FILES”.
-f config-file, --file config-file
Use the given config file instead of the one specified by GIT_CONFIG.
--blob blob
Similar to _-_-_f_i_l_e but use the given blob instead of a file. E.g. you can use
_m_a_s_t_e_r_:_._g_i_t_m_o_d_u_l_e_s to read values from the file _._g_i_t_m_o_d_u_l_e_s in the master branch. See
"SPECIFYING REVISIONS" section in ggiittrreevviissiioonnss(7) for a more complete list of ways to
spell blob names.
--remove-section
Remove the given section from the configuration file.
--rename-section
Rename the given section to a new name.
--unset
Remove the line matching the key from config file.
--unset-all
Remove all lines matching the key from config file.
-l, --list
List all variables set in config file, along with their values.
--bool
_g_i_t _c_o_n_f_i_g will ensure that the output is "true" or "false"
--int
_g_i_t _c_o_n_f_i_g will ensure that the output is a simple decimal number. An optional value
suffix of _k, _m, or _g in the config file will cause the value to be multiplied by 1024,
1048576, or 1073741824 prior to output.
--bool-or-int
_g_i_t _c_o_n_f_i_g will ensure that the output matches the format of either --bool or --int, as
described above.
--path
_g_i_t_-_c_o_n_f_i_g will expand leading _~ to the value of _$_H_O_M_E, and _~_u_s_e_r to the home directory
for the specified user. This option has no effect when setting the value (but you can
use _g_i_t _c_o_n_f_i_g _b_l_a _~_/ from the command line to let your shell do the expansion).
-z, --null
For all options that output values and/or keys, always end values with the null
character (instead of a newline). Use newline instead as a delimiter between key and
value. This allows for secure parsing of the output without getting confused e.g. by
values that contain line breaks.
--name-only
Output only the names of config variables for --list or --get-regexp.
--get-colorbool name [stdout-is-tty]
Find the color setting for name (e.g. color.diff) and output "true" or "false".
stdout-is-tty should be either "true" or "false", and is taken into account when
configuration says "auto". If stdout-is-tty is missing, then checks the standard output
of the command itself, and exits with status 0 if color is to be used, or exits with
status 1 otherwise. When the color setting for name is undefined, the command uses
color.ui as fallback.
--get-color name [default]
Find the color configured for name (e.g. color.diff.new) and output it as the ANSI
color escape sequence to the standard output. The optional default parameter is used
instead, if there is no color configured for name.
-e, --edit
Opens an editor to modify the specified config file; either _-_-_s_y_s_t_e_m, _-_-_g_l_o_b_a_l, or
repository (default).
--[no-]includes
Respect include.* directives in config files when looking up values. Defaults to on.
FFIILLEESS
If not set explicitly with _-_-_f_i_l_e, there are four files where _g_i_t _c_o_n_f_i_g will search for
configuration options:
$(prefix)/etc/gitconfig
System-wide configuration file.
$XDG_CONFIG_HOME/git/config
Second user-specific configuration file. If $XDG_CONFIG_HOME is not set or empty,
$HOME/.config/git/config will be used. Any single-valued variable set in this file will
be overwritten by whatever is in ~/.gitconfig. It is a good idea not to create this file
if you sometimes use older versions of Git, as support for this file was added fairly
recently.
~/.gitconfig
User-specific configuration file. Also called "global" configuration file.
$GIT_DIR/config
Repository specific configuration file.
If no further options are given, all reading options will read all of these files that are
available. If the global or the system-wide configuration file are not available they will
be ignored. If the repository configuration file is not available or readable, _g_i_t _c_o_n_f_i_g
will exit with a non-zero error code. However, in neither case will an error message be
issued.
The files are read in the order given above, with last value found taking precedence over
values read earlier. When multiple values are taken then all values of a key from all files
will be used.
All writing options will per default write to the repository specific configuration file.
Note that this also affects options like _-_-_r_e_p_l_a_c_e_-_a_l_l and _-_-_u_n_s_e_t. _g_i_t _c_o_n_f_i_g wwiillll oonnllyy
eevveerr cchhaannggee oonnee ffiillee aatt aa ttiimmee.
You can override these rules either by command-line options or by environment variables. The
_-_-_g_l_o_b_a_l and the _-_-_s_y_s_t_e_m options will limit the file used to the global or system-wide file
respectively. The GIT_CONFIG environment variable has a similar effect, but you can specify
any filename you want.
EENNVVIIRROONNMMEENNTT
GIT_CONFIG
Take the configuration from the given file instead of .git/config. Using the "--global"
option forces this to ~/.gitconfig. Using the "--system" option forces this to
$(prefix)/etc/gitconfig.
GIT_CONFIG_NOSYSTEM
Whether to skip reading settings from the system-wide $(prefix)/etc/gitconfig file. See
ggiitt(1) for details.
See also the section called “FILES”.
EEXXAAMMPPLLEESS
Given a .git/config like this:
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
; Don't trust file modes
filemode = false
; Our diff algorithm
[diff]
external = /usr/local/bin/diff-wrapper
renames = true
; Proxy settings
[core]
gitproxy=proxy-command for kernel.org
gitproxy=default-proxy ; for all the rest
; HTTP
[http]
sslVerify
[http "https://weak.example.com"]
sslVerify = false
cookieFile = /tmp/cookie.txt
you can set the filemode to true with
% git config core.filemode true
The hypothetical proxy command entries actually have a postfix to discern what URL they
apply to. Here is how to change the entry for kernel.org to "ssh".
% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
This makes sure that only the key/value pair for kernel.org is replaced.
To delete the entry for renames, do
% git config --unset diff.renames
If you want to delete an entry for a multivar (like core.gitproxy above), you have to
provide a regex matching the value of exactly one line.
To query the value for a given key, do
% git config --get core.filemode
or
% git config core.filemode
or, to query a multivar:
% git config --get core.gitproxy "for kernel.org$"
If you want to know all the values for a multivar, do:
% git config --get-all core.gitproxy
If you like to live dangerously, you can replace aallll core.gitproxy by a new one with
% git config --replace-all core.gitproxy ssh
However, if you really only want to replace the line for the default proxy, i.e. the one
without a "for ..." postfix, do something like this:
% git config core.gitproxy ssh '! for '
To actually match only values with an exclamation mark, you have to
% git config section.key value '[!]'
To add a new proxy, without altering any of the existing ones, use
% git config --add core.gitproxy '"proxy-command" for example.com'
An example to use customized color from the configuration in your script:
#!/bin/sh
WS=$(git config --get-color color.diff.whitespace "blue reverse")
RESET=$(git config --get-color "" "reset")
echo "${WS}your whitespace color or blue reverse${RESET}"
For URLs in https://weak.example.com, http.sslVerify is set to false, while it is set to
true for all others:
% git config --bool --get-urlmatch http.sslverify https://good.example.com
true
% git config --bool --get-urlmatch http.sslverify https://weak.example.com
false
% git config --get-urlmatch http https://weak.example.com
http.cookieFile /tmp/cookie.txt
http.sslverify false
CCOONNFFIIGGUURRAATTIIOONN FFIILLEE
The Git configuration file contains a number of variables that affect the Git commands'
behavior. The .git/config file in each repository is used to store the configuration for
that repository, and $HOME/.gitconfig is used to store a per-user configuration as fallback
values for the .git/config file. The file /etc/gitconfig can be used to store a system-wide
default configuration.
The configuration variables are used by both the Git plumbing and the porcelains. The
variables are divided into sections, wherein the fully qualified variable name of the
variable itself is the last dot-separated segment and the section name is everything before
the last dot. The variable names are case-insensitive, allow only alphanumeric characters
and -, and must start with an alphabetic character. Some variables may appear multiple
times; we say then that the variable is multivalued.
SSyynnttaaxx
The syntax is fairly flexible and permissive; whitespaces are mostly ignored. The _# and _;
characters begin comments to the end of line, blank lines are ignored.
The file consists of sections and variables. A section begins with the name of the section
in square brackets and continues until the next section begins. Section names are
case-insensitive. Only alphanumeric characters, - and . are allowed in section names. Each
variable must belong to some section, which means that there must be a section header before
the first setting of a variable.
Sections can be further divided into subsections. To begin a subsection put its name in
double quotes, separated by space from the section name, in the section header, like in the
example below:
[section "subsection"]
Subsection names are case sensitive and can contain any characters except newline
(doublequote " and backslash can be included by escaping them as \" and \\, respectively).
Section headers cannot span multiple lines. Variables may belong directly to a section or to
a given subsection. You can have [section] if you have [section "subsection"], but you don’t
need to.
There is also a deprecated [section.subsection] syntax. With this syntax, the subsection
name is converted to lower-case and is also compared case sensitively. These subsection
names follow the same restrictions as section names.
All the other lines (and the remainder of the line after the section header) are recognized
as setting variables, in the form _n_a_m_e _= _v_a_l_u_e (or just _n_a_m_e, which is a short-hand to say
that the variable is the boolean "true"). The variable names are case-insensitive, allow
only alphanumeric characters and -, and must start with an alphabetic character.
A line that defines a value can be continued to the next line by ending it with a \; the
backquote and the end-of-line are stripped. Leading whitespaces after _n_a_m_e _=, the remainder
of the line after the first comment character _# or _;, and trailing whitespaces of the line
are discarded unless they are enclosed in double quotes. Internal whitespaces within the
value are retained verbatim.
Inside double quotes, double quote " and backslash \ characters must be escaped: use \" for
" and \\ for \.
The following escape sequences (beside \" and \\) are recognized: \n for newline character
(NL), \t for horizontal tabulation (HT, TAB) and \b for backspace (BS). Other char escape
sequences (including octal escape sequences) are invalid.
IInncclluuddeess
You can include one config file from another by setting the special include.path variable to
the name of the file to be included. The included file is expanded immediately, as if its
contents had been found at the location of the include directive. If the value of the
include.path variable is a relative path, the path is considered to be relative to the
configuration file in which the include directive was found. The value of include.path is
subject to tilde expansion: ~/ is expanded to the value of $HOME, and ~user/ to the
specified user’s home directory. See below for examples.
EExxaammppllee
# Core variables
[core]
; Don't trust file modes
filemode = false
# Our diff algorithm
[diff]
external = /usr/local/bin/diff-wrapper
renames = true
[branch "devel"]
remote = origin
merge = refs/heads/devel
# Proxy settings
[core]
gitProxy="ssh" for "kernel.org"
gitProxy=default-proxy ; for the rest
[include]
path = /path/to/foo.inc ; include by absolute path
path = foo ; expand "foo" relative to the current file
path = ~/foo ; expand "foo" in your $HOME directory
VVaalluueess
Values of many variables are treated as a simple string, but there are variables that take
values of specific types and there are rules as to how to spell them.
boolean
When a variable is said to take a boolean value, many synonyms are accepted for _t_r_u_e and
_f_a_l_s_e; these are all case-insensitive.
true
Boolean true can be spelled as yes, on, true, or 1. Also, a variable defined without
= <value> is taken as true.
false
Boolean false can be spelled as no, off, false, or 0.
When converting value to the canonical form using _-_-_b_o_o_l type specifier; _g_i_t _c_o_n_f_i_g
will ensure that the output is "true" or "false" (spelled in lowercase).
integer
The value for many variables that specify various sizes can be suffixed with k, M,... to
mean "scale the number by 1024", "by 1024x1024", etc.
color
The value for a variables that takes a color is a list of colors (at most two) and
attributes (at most one), separated by spaces. The colors accepted are normal, black,
red, green, yellow, blue, magenta, cyan and white; the attributes are bold, dim, ul,
blink and reverse. The first color given is the foreground; the second is the
background. The position of the attribute, if any, doesn’t matter. Attributes may be
turned off specifically by prefixing them with no (e.g., noreverse, noul, etc).
Colors (foreground and background) may also be given as numbers between 0 and 255; these
use ANSI 256-color mode (but note that not all terminals may support this). If your
terminal supports it, you may also specify 24-bit RGB values as hex, like #ff0ab3.
The attributes are meant to be reset at the beginning of each item in the colored
output, so setting color.decorate.branch to black will paint that branch name in a plain
black, even if the previous thing on the same output line (e.g. opening parenthesis
before the list of branch names in log --decorate output) is set to be painted with bold
or some other attribute.
VVaarriiaabblleess
Note that this list is non-comprehensive and not necessarily complete. For command-specific
variables, you will find a more detailed description in the appropriate manual page.
Other git-related tools may and do use their own variables. When inventing new variables for
use in your own tool, make sure their names do not conflict with those that are used by Git
itself and other popular tools, and describe them in your documentation.
advice.*
These variables control various optional help messages designed to aid new users. All
_a_d_v_i_c_e_._* variables default to _t_r_u_e, and you can tell Git that you do not need help by
setting these to _f_a_l_s_e:
pushUpdateRejected
Set this variable to _f_a_l_s_e if you want to disable _p_u_s_h_N_o_n_F_F_C_u_r_r_e_n_t,
_p_u_s_h_N_o_n_F_F_M_a_t_c_h_i_n_g, _p_u_s_h_A_l_r_e_a_d_y_E_x_i_s_t_s, _p_u_s_h_F_e_t_c_h_F_i_r_s_t, and _p_u_s_h_N_e_e_d_s_F_o_r_c_e
simultaneously.
pushNonFFCurrent
Advice shown when ggiitt--ppuusshh(1) fails due to a non-fast-forward update to the current
branch.
pushNonFFMatching
Advice shown when you ran ggiitt--ppuusshh(1) and pushed _m_a_t_c_h_i_n_g _r_e_f_s explicitly (i.e. you
used _:, or specified a refspec that isn’t your current branch) and it resulted in a
non-fast-forward error.
pushAlreadyExists
Shown when ggiitt--ppuusshh(1) rejects an update that does not qualify for fast-forwarding
(e.g., a tag.)
pushFetchFirst
Shown when ggiitt--ppuusshh(1) rejects an update that tries to overwrite a remote ref that
points at an object we do not have.
pushNeedsForce
Shown when ggiitt--ppuusshh(1) rejects an update that tries to overwrite a remote ref that
points at an object that is not a commit-ish, or make the remote ref point at an
object that is not a commit-ish.
statusHints
Show directions on how to proceed from the current state in the output of ggiitt--
ssttaattuuss(1), in the template shown when writing commit messages in ggiitt--ccoommmmiitt(1), and
in the help message shown by ggiitt--cchheecckkoouutt(1) when switching branch.
statusUoption
Advise to consider using the -u option to ggiitt--ssttaattuuss(1) when the command takes more
than 2 seconds to enumerate untracked files.
commitBeforeMerge
Advice shown when ggiitt--mmeerrggee(1) refuses to merge to avoid overwriting local changes.
resolveConflict
Advice shown by various commands when conflicts prevent the operation from being
performed.
implicitIdentity
Advice on how to set your identity configuration when your information is guessed
from the system username and domain name.
detachedHead
Advice shown when you used ggiitt--cchheecckkoouutt(1) to move to the detach HEAD state, to
instruct how to create a local branch after the fact.
amWorkDir
Advice that shows the location of the patch file when ggiitt--aamm(1) fails to apply it.
rmHints
In case of failure in the output of ggiitt--rrmm(1), show directions on how to proceed
from the current state.
core.fileMode
Tells Git if the executable bit of files in the working tree is to be honored.
Some filesystems lose the executable bit when a file that is marked as executable is
checked out, or checks out an non-executable file with executable bit on. ggiitt--cclloonnee(1)
or ggiitt--iinniitt(1) probe the filesystem to see if it handles the executable bit correctly
and this variable is automatically set as necessary.
A repository, however, may be on a filesystem that handles the filemode correctly, and
this variable is set to _t_r_u_e when created, but later may be made accessible from another
environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a
Cygwin created repository with Git for Windows or Eclipse). In such a case it may be
necessary to set this variable to _f_a_l_s_e. See ggiitt--uuppddaattee--iinnddeexx(1).
The default is true (when core.filemode is not specified in the config file).
core.ignoreCase
If true, this option enables various workarounds to enable Git to work better on
filesystems that are not case sensitive, like FAT. For example, if a directory listing
finds "makefile" when Git expects "Makefile", Git will assume it is really the same
file, and continue to remember it as "Makefile".
The default is false, except ggiitt--cclloonnee(1) or ggiitt--iinniitt(1) will probe and set
core.ignoreCase true if appropriate when the repository is created.
core.precomposeUnicode
This option is only used by Mac OS implementation of Git. When
core.precomposeUnicode=true, Git reverts the unicode decomposition of filenames done by
Mac OS. This is useful when sharing a repository between Mac OS and Linux or Windows.
(Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7). When false, file
names are handled fully transparent by Git, which is backward compatible with older
versions of Git.
core.protectHFS
If set to true, do not allow checkout of paths that would be considered equivalent to
.git on an HFS+ filesystem. Defaults to true on Mac OS, and false elsewhere.
core.protectNTFS
If set to true, do not allow checkout of paths that would cause problems with the NTFS
filesystem, e.g. conflict with 8.3 "short" names. Defaults to true on Windows, and false
elsewhere.
core.trustctime
If false, the ctime differences between the index and the working tree are ignored;
useful when the inode change time is regularly modified by something outside Git (file
system crawlers and some backup systems). See ggiitt--uuppddaattee--iinnddeexx(1). True by default.
core.checkStat
Determines which stat fields to match between the index and work tree. The user can set
this to _d_e_f_a_u_l_t or _m_i_n_i_m_a_l. Default (or explicitly _d_e_f_a_u_l_t), is to check all fields,
including the sub-second part of mtime and ctime.
core.quotePath
The commands that output paths (e.g. _l_s_-_f_i_l_e_s, _d_i_f_f), when not given the -z option,
will quote "unusual" characters in the pathname by enclosing the pathname in a
double-quote pair and with backslashes the same way strings in C source code are quoted.
If this variable is set to false, the bytes higher than 0x80 are not quoted but output
as verbatim. Note that double quote, backslash and control characters are always quoted
without -z regardless of the setting of this variable.
core.eol
Sets the line ending type to use in the working directory for files that have the text
property set. Alternatives are _l_f, _c_r_l_f and _n_a_t_i_v_e, which uses the platform’s native
line ending. The default value is native. See ggiittaattttrriibbuutteess(5) for more information on
end-of-line conversion.
core.safecrlf
If true, makes Git check if converting CRLF is reversible when end-of-line conversion is
active. Git will verify if a command modifies a file in the work tree either directly or
indirectly. For example, committing a file followed by checking out the same file should
yield the original file in the work tree. If this is not the case for the current
setting of core.autocrlf, Git will reject the file. The variable can be set to "warn",
in which case Git will only warn about an irreversible conversion but continue the
operation.
CRLF conversion bears a slight chance of corrupting data. When it is enabled, Git will
convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a
mixture of LF and CRLF before the commit cannot be recreated by Git. For text files this
is the right thing to do: it corrects line endings such that we have only LF line
endings in the repository. But for binary files that are accidentally classified as text
the conversion can corrupt data.
If you recognize such corruption early you can easily fix it by setting the conversion
type explicitly in .gitattributes. Right after committing you still have the original
file in your work tree and this file is not yet corrupted. You can explicitly tell Git
that this file is binary and Git will handle the file appropriately.
Unfortunately, the desired effect of cleaning up text files with mixed line endings and
the undesired effect of corrupting binary files cannot be distinguished. In both cases
CRLFs are removed in an irreversible way. For text files this is the right thing to do
because CRLFs are line endings, while for binary files converting CRLFs corrupts data.
Note, this safety check does not mean that a checkout will generate a file identical to
the original file for a different setting of core.eol and core.autocrlf, but only for
the current one. For example, a text file with LF would be accepted with core.eol=lf and
could later be checked out with core.eol=crlf, in which case the resulting file would
contain CRLF, although the original file contained LF. However, in both work trees the
line endings would be consistent, that is either all LF or all CRLF, but never mixed. A
file with mixed line endings would be reported by the core.safecrlf mechanism.
core.autocrlf
Setting this variable to "true" is almost the same as setting the text attribute to
"auto" on all files except that text files are not guaranteed to be normalized: files
that contain CRLF in the repository will not be touched. Use this setting if you want to
have CRLF line endings in your working directory even though the repository does not
have normalized line endings. This variable can be set to _i_n_p_u_t, in which case no output
conversion is performed.
core.symlinks
If false, symbolic links are checked out as small plain files that contain the link
text. ggiitt--uuppddaattee--iinnddeexx(1) and ggiitt--aadddd(1) will not change the recorded type to regular
file. Useful on filesystems like FAT that do not support symbolic links.
The default is true, except ggiitt--cclloonnee(1) or ggiitt--iinniitt(1) will probe and set core.symlinks
false if appropriate when the repository is created.
core.gitProxy
A "proxy command" to execute (as _c_o_m_m_a_n_d _h_o_s_t _p_o_r_t) instead of establishing direct
connection to the remote server when using the Git protocol for fetching. If the
variable value is in the "COMMAND for DOMAIN" format, the command is applied only on
hostnames ending with the specified domain string. This variable may be set multiple
times and is matched in the given order; the first match wins.
Can be overridden by the _G_I_T___P_R_O_X_Y___C_O_M_M_A_N_D environment variable (which always applies
universally, without the special "for" handling).
The special string none can be used as the proxy command to specify that no proxy be
used for a given domain pattern. This is useful for excluding servers inside a firewall
from proxy use, while defaulting to a common proxy for external domains.
core.ignoreStat
If true, Git will avoid using lstat() calls to detect if files have changed by setting
the "assume-unchanged" bit for those tracked files which it has updated identically in
both the index and working tree.
When files are modified outside of Git, the user will need to stage the modified files
explicitly (e.g. see _E_x_a_m_p_l_e_s section in ggiitt--uuppddaattee--iinnddeexx(1)). Git will not normally
detect changes to those files.
This is useful on systems where lstat() calls are very slow, such as CIFS/Microsoft
Windows.
False by default.
core.preferSymlinkRefs
Instead of the default "symref" format for HEAD and other symbolic reference files, use
symbolic links. This is sometimes needed to work with old scripts that expect HEAD to be
a symbolic link.
core.bare
If true this repository is assumed to be _b_a_r_e and has no working directory associated
with it. If this is the case a number of commands that require a working directory will
be disabled, such as ggiitt--aadddd(1) or ggiitt--mmeerrggee(1).
This setting is automatically guessed by ggiitt--cclloonnee(1) or ggiitt--iinniitt(1) when the repository
was created. By default a repository that ends in "/.git" is assumed to be not bare
(bare = false), while all other repositories are assumed to be bare (bare = true).
core.worktree
Set the path to the root of the working tree. If GIT_COMMON_DIR environment variable is
set, core.worktree is ignored and not used for determining the root of working tree.
This can be overridden by the GIT_WORK_TREE environment variable and the _-_-_w_o_r_k_-_t_r_e_e
command-line option. The value can be an absolute path or relative to the path to the
.git directory, which is either specified by --git-dir or GIT_DIR, or automatically
discovered. If --git-dir or GIT_DIR is specified but none of --work-tree, GIT_WORK_TREE
and core.worktree is specified, the current working directory is regarded as the top
level of your working tree.
Note that this variable is honored even when set in a configuration file in a ".git"
subdirectory of a directory and its value differs from the latter directory (e.g.
"/path/to/.git/config" has core.worktree set to "/different/path"), which is most likely
a misconfiguration. Running Git commands in the "/path/to" directory will still use
"/different/path" as the root of the work tree and can cause confusion unless you know
what you are doing (e.g. you are creating a read-only snapshot of the same index to a
location different from the repository’s usual working tree).
core.logAllRefUpdates
Enable the reflog. Updates to a ref <ref> is logged to the file "$GIT_DIR/logs/<ref>",
by appending the new and old SHA-1, the date/time and the reason of the update, but only
when the file exists. If this configuration variable is set to true, missing
"$GIT_DIR/logs/<ref>" file is automatically created for branch heads (i.e. under
refs/heads/), remote refs (i.e. under refs/remotes/), note refs (i.e. under
refs/notes/), and the symbolic ref HEAD.
This information can be used to determine what commit was the tip of a branch "2 days
ago".
This value is true by default in a repository that has a working directory associated
with it, and false by default in a bare repository.
core.repositoryFormatVersion
Internal variable identifying the repository format and layout version.
core.sharedRepository
When _g_r_o_u_p (or _t_r_u_e), the repository is made shareable between several users in a group
(making sure all the files and objects are group-writable). When _a_l_l (or _w_o_r_l_d or
_e_v_e_r_y_b_o_d_y), the repository will be readable by all users, additionally to being
group-shareable. When _u_m_a_s_k (or _f_a_l_s_e), Git will use permissions reported by umask(2).
When _0_x_x_x, where _0_x_x_x is an octal number, files in the repository will have this mode
value. _0_x_x_x will override user’s umask value (whereas the other options will only
override requested parts of the user’s umask value). Examples: _0_6_6_0 will make the repo
read/write-able for the owner and group, but inaccessible to others (equivalent to _g_r_o_u_p
unless umask is e.g. _0_0_2_2). _0_6_4_0 is a repository that is group-readable but not
group-writable. See ggiitt--iinniitt(1). False by default.
core.warnAmbiguousRefs
If true, Git will warn you if the ref name you passed it is ambiguous and might match
multiple refs in the repository. True by default.
core.compression
An integer -1..9, indicating a default compression level. -1 is the zlib default. 0
means no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. If
set, this provides a default to other compression variables, such as
_c_o_r_e_._l_o_o_s_e_C_o_m_p_r_e_s_s_i_o_n and _p_a_c_k_._c_o_m_p_r_e_s_s_i_o_n.
core.looseCompression
An integer -1..9, indicating the compression level for objects that are not in a pack
file. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size
tradeoffs, 9 being slowest. If not set, defaults to core.compression. If that is not
set, defaults to 1 (best speed).
core.packedGitWindowSize
Number of bytes of a pack file to map into memory in a single mapping operation. Larger
window sizes may allow your system to process a smaller number of large pack files more
quickly. Smaller window sizes will negatively affect performance due to increased calls
to the operating system’s memory manager, but may improve performance when accessing a
large number of large pack files.
Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32 MiB on 32 bit
platforms and 1 GiB on 64 bit platforms. This should be reasonable for all
users/operating systems. You probably do not need to adjust this value.
Common unit suffixes of _k, _m, or _g are supported.
core.packedGitLimit
Maximum number of bytes to map simultaneously into memory from pack files. If Git needs
to access more than this many bytes at once to complete an operation it will unmap
existing regions to reclaim virtual address space within the process.
Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms. This should be
reasonable for all users/operating systems, except on the largest projects. You probably
do not need to adjust this value.
Common unit suffixes of _k, _m, or _g are supported.
core.deltaBaseCacheLimit
Maximum number of bytes to reserve for caching base objects that may be referenced by
multiple deltified objects. By storing the entire decompressed base objects in a cache
Git is able to avoid unpacking and decompressing frequently used base objects multiple
times.
Default is 96 MiB on all platforms. This should be reasonable for all users/operating
systems, except on the largest projects. You probably do not need to adjust this value.
Common unit suffixes of _k, _m, or _g are supported.
core.bigFileThreshold
Files larger than this size are stored deflated, without attempting delta compression.
Storing large files without delta compression avoids excessive memory usage, at the
slight expense of increased disk usage. Additionally files larger than this size are
always treated as binary.
Default is 512 MiB on all platforms. This should be reasonable for most projects as
source code and other text files can still be delta compressed, but larger binary media
files won’t be.
Common unit suffixes of _k, _m, or _g are supported.
core.excludesFile
In addition to _._g_i_t_i_g_n_o_r_e (per-directory) and _._g_i_t_/_i_n_f_o_/_e_x_c_l_u_d_e, Git looks into this
file for patterns of files which are not meant to be tracked. "~/" is expanded to the
value of $HOME and "~user/" to the specified user’s home directory. Its default value is
$XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty,
$HOME/.config/git/ignore is used instead. See ggiittiiggnnoorree(5).
core.askPass
Some commands (e.g. svn and http interfaces) that interactively ask for a password can
be told to use an external program given via the value of this variable. Can be
overridden by the _G_I_T___A_S_K_P_A_S_S environment variable. If not set, fall back to the value
of the _S_S_H___A_S_K_P_A_S_S environment variable or, failing that, a simple password prompt. The
external program shall be given a suitable prompt as command-line argument and write the
password on its STDOUT.
core.attributesFile
In addition to _._g_i_t_a_t_t_r_i_b_u_t_e_s (per-directory) and _._g_i_t_/_i_n_f_o_/_a_t_t_r_i_b_u_t_e_s, Git looks into
this file for attributes (see ggiittaattttrriibbuutteess(5)). Path expansions are made the same way
as for core.excludesFile. Its default value is $XDG_CONFIG_HOME/git/attributes. If
$XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/attributes is used
instead.
core.editor
Commands such as commit and tag that lets you edit messages by launching an editor uses
the value of this variable when it is set, and the environment variable GIT_EDITOR is
not set. See ggiitt--vvaarr(1).
core.commentChar
Commands such as commit and tag that lets you edit messages consider a line that begins
with this character commented, and removes them after the editor returns (default _#).
If set to "auto", git-commit would select a character that is not the beginning
character of any line in existing commit messages.
core.packedRefsTimeout
The length of time, in milliseconds, to retry when trying to lock the packed-refs file.
Value 0 means not to retry at all; -1 means to try indefinitely. Default is 1000 (i.e.,
retry for 1 second).
sequence.editor
Text editor used by git rebase -i for editing the rebase instruction file. The value is
meant to be interpreted by the shell when it is used. It can be overridden by the
GIT_SEQUENCE_EDITOR environment variable. When not configured the default commit message
editor is used instead.
core.pager
Text viewer for use by Git commands (e.g., _l_e_s_s). The value is meant to be interpreted
by the shell. The order of preference is the $GIT_PAGER environment variable, then
core.pager configuration, then $PAGER, and then the default chosen at compile time
(usually _l_e_s_s).
When the LESS environment variable is unset, Git sets it to FRX (if LESS environment
variable is set, Git does not change it at all). If you want to selectively override
Git’s default setting for LESS, you can set core.pager to e.g. less -S. This will be
passed to the shell by Git, which will translate the final command to LESS=FRX less -S.
The environment does not set the S option but the command line does, instructing less to
truncate long lines. Similarly, setting core.pager to less -+F will deactivate the F
option specified by the environment from the command-line, deactivating the "quit if one
screen" behavior of less. One can specifically activate some flags for particular
commands: for example, setting pager.blame to less -S enables line truncation only for
git blame.
Likewise, when the LV environment variable is unset, Git sets it to -c. You can override
this setting by exporting LV with another value or setting core.pager to lv +c.
core.whitespace
A comma separated list of common whitespace problems to notice. _g_i_t _d_i_f_f will use
color.diff.whitespace to highlight them, and _g_i_t _a_p_p_l_y _-_-_w_h_i_t_e_s_p_a_c_e_=_e_r_r_o_r will consider
them as errors. You can prefix - to disable any of them (e.g. -trailing-space):
· blank-at-eol treats trailing whitespaces at the end of the line as an error (enabled
by default).
· space-before-tab treats a space character that appears immediately before a tab
character in the initial indent part of the line as an error (enabled by default).
· indent-with-non-tab treats a line that is indented with space characters instead of
the equivalent tabs as an error (not enabled by default).
· tab-in-indent treats a tab character in the initial indent part of the line as an
error (not enabled by default).
· blank-at-eof treats blank lines added at the end of file as an error (enabled by
default).
· trailing-space is a short-hand to cover both blank-at-eol and blank-at-eof.
· cr-at-eol treats a carriage-return at the end of line as part of the line
terminator, i.e. with it, trailing-space does not trigger if the character before
such a carriage-return is not a whitespace (not enabled by default).
· tabwidth=<n> tells how many character positions a tab occupies; this is relevant for
indent-with-non-tab and when Git fixes tab-in-indent errors. The default tab width
is 8. Allowed values are 1 to 63.
core.fsyncObjectFiles
This boolean will enable _f_s_y_n_c_(_) when writing object files.
This is a total waste of time and effort on a filesystem that orders data writes
properly, but can be useful for filesystems that do not use journalling (traditional
UNIX filesystems) or that only journal metadata and not file contents (OS X’s HFS+, or
Linux ext3 with "data=writeback").
core.preloadIndex
Enable parallel index preload for operations like _g_i_t _d_i_f_f
This can speed up operations like _g_i_t _d_i_f_f and _g_i_t _s_t_a_t_u_s especially on filesystems like
NFS that have weak caching semantics and thus relatively high IO latencies. When
enabled, Git will do the index comparison to the filesystem data in parallel, allowing
overlapping IO’s. Defaults to true.
core.createObject
You can set this to _l_i_n_k, in which case a hardlink followed by a delete of the source
are used to make sure that object creation will not overwrite existing objects.
On some file system/operating system combinations, this is unreliable. Set this config
setting to _r_e_n_a_m_e there; However, This will remove the check that makes sure that
existing object files will not get overwritten.
core.notesRef
When showing commit messages, also show notes which are stored in the given ref. The ref
must be fully qualified. If the given ref does not exist, it is not an error but means
that no notes should be printed.
This setting defaults to "refs/notes/commits", and it can be overridden by the
_G_I_T___N_O_T_E_S___R_E_F environment variable. See ggiitt--nnootteess(1).
core.sparseCheckout
Enable "sparse checkout" feature. See section "Sparse checkout" in ggiitt--rreeaadd--ttrreeee(1) for
more information.
core.abbrev
Set the length object names are abbreviated to. If unspecified, many commands abbreviate
to 7 hexdigits, which may not be enough for abbreviated object names to stay unique for
sufficiently long time.
add.ignoreErrors, add.ignore-errors (deprecated)
Tells _g_i_t _a_d_d to continue adding files when some files cannot be added due to indexing
errors. Equivalent to the _-_-_i_g_n_o_r_e_-_e_r_r_o_r_s option of ggiitt--aadddd(1). add.ignore-errors is
deprecated, as it does not follow the usual naming convention for configuration
variables.
alias.*
Command aliases for the ggiitt(1) command wrapper - e.g. after defining "alias.last =
cat-file commit HEAD", the invocation "git last" is equivalent to "git cat-file commit
HEAD". To avoid confusion and troubles with script usage, aliases that hide existing Git
commands are ignored. Arguments are split by spaces, the usual shell quoting and
escaping is supported. A quote pair or a backslash can be used to quote them.
If the alias expansion is prefixed with an exclamation point, it will be treated as a
shell command. For example, defining "alias.new = !gitk --all --not ORIG_HEAD", the
invocation "git new" is equivalent to running the shell command "gitk --all --not
ORIG_HEAD". Note that shell commands will be executed from the top-level directory of a
repository, which may not necessarily be the current directory. _G_I_T___P_R_E_F_I_X is set as
returned by running _g_i_t _r_e_v_-_p_a_r_s_e _-_-_s_h_o_w_-_p_r_e_f_i_x from the original current directory. See
ggiitt--rreevv--ppaarrssee(1).
am.keepcr
If true, git-am will call git-mailsplit for patches in mbox format with parameter
_-_-_k_e_e_p_-_c_r. In this case git-mailsplit will not remove \r from lines ending with \r\n.
Can be overridden by giving _-_-_n_o_-_k_e_e_p_-_c_r from the command line. See ggiitt--aamm(1), ggiitt--
mmaaiillsspplliitt(1).
am.threeWay
By default, git am will fail if the patch does not apply cleanly. When set to true, this
setting tells git am to fall back on 3-way merge if the patch records the identity of
blobs it is supposed to apply to and we have those blobs available locally (equivalent
to giving the --3way option from the command line). Defaults to false. See ggiitt--aamm(1).
apply.ignoreWhitespace
When set to _c_h_a_n_g_e, tells _g_i_t _a_p_p_l_y to ignore changes in whitespace, in the same way as
the _-_-_i_g_n_o_r_e_-_s_p_a_c_e_-_c_h_a_n_g_e option. When set to one of: no, none, never, false tells _g_i_t
_a_p_p_l_y to respect all whitespace differences. See ggiitt--aappppllyy(1).
apply.whitespace
Tells _g_i_t _a_p_p_l_y how to handle whitespaces, in the same way as the _-_-_w_h_i_t_e_s_p_a_c_e option.
See ggiitt--aappppllyy(1).
branch.autoSetupMerge
Tells _g_i_t _b_r_a_n_c_h and _g_i_t _c_h_e_c_k_o_u_t to set up new branches so that ggiitt--ppuullll(1) will
appropriately merge from the starting point branch. Note that even if this option is not
set, this behavior can be chosen per-branch using the --track and --no-track options.
The valid settings are: false — no automatic setup is done; true — automatic setup is
done when the starting point is a remote-tracking branch; always — automatic setup is
done when the starting point is either a local branch or remote-tracking branch. This
option defaults to true.