password - git config: lista todas las variables y sus valores por defecto

git push

Question

Al igual que el comando MySQL show variables que muestra todas las variables y no solo las definidas en my.ini , me gustaría ver una lista de todas las variables de configuración en git junto con sus valores predeterminados, y no solo las definidas en my ~/.gitconfig .

es posible?

Answer 1

Eso fue debatido en este hilo en 2013 , solicitado por Sebastian Schuberth , Jeff King ( Peff ) agregando:

El resultado esperado es ciertamente un problema, pero el problema es más fundamental que eso: git config ni siquiera sabe cuál es el valor predeterminado para cualquier opción dada.

Se supone que la persona que llama sabe qué hacer con un valor no establecido. Y esto no tiene nada que ver con git config ; El código C interno funciona de la misma manera.
Los valores predeterminados reales ni siquiera son necesariamente expresables a través de la configuración .
Por ejemplo, sé que http.receivepack considera que "unset" no está http.receivepack como " true " o " false ", pero si lo configura puede producir solo uno de esos dos últimos valores.
Estoy seguro de que también hay otros (me di cuenta de que uno esta semana).

( Por ejemplo: gc.prune )

Ciertamente, podría ver un argumento de que el mundo sería un lugar mejor si el código tuviera una gran tabla de opciones y sus descripciones, valores posibles y valores predeterminados, y si lo utilizáramos para generar documentación y validar las entradas.
Pero nadie se ha tomado la molestia de construir esa tabla y convertir a todos los que llaman. Y como mencionó Jakub (Jakub Narębski) , una tabla central de este tipo no puede hacer nada por los programas externos que almacenan su configuración junto con los git.

En breve:

git config ni siquiera conoce ninguna de las opciones o valores que administra, pero solo es una interfaz "tonta" para escribir / leer lo que sea que pase a / desde un archivo.

Nota: git config se introdujo en commit 1771299 (git 0.99.9a, octubre de 2005)

Diferentes programas pueden reaccionar a diferentes opciones de configuración, aunque siempre deben recurrir a "git_default_config ()" en cualquier nombre de opción de configuración que no reconozcan.

Así que internamente, hay una forma de cargar la configuración predeterminada, utilizada tan recientemente como commit 72549df, git 2.2.0-rc1, noviembre de 2014 , por el mismo Peff:

Cuando iniciamos el programa git-fetch, llamamos a git_config para cargar toda la configuración, pero nuestra devolución de llamada solo procesa la opción fetch.prune ; no encadenamos a git_default_config en absoluto.

Esto significa que no podemos cargar alguna configuración de núcleo que tendrá un efecto. Por ejemplo, no core.logAllRefUpdates , lo que influye en si creamos o no reinos en un repositorio simple.

Simplemente cargemos la configuración del núcleo al inicio de la búsqueda, para que sepamos que la tenemos

Vea otro ejemplo con commit 3e1dd17, git 1.7.7-rc1, agosto de 2011 con la configuración de color predeterminada.

Answer 2

Este método no le proporcionará su configuración junto con los valores predeterminados, pero es un método bastante sólido para obtener los ajustes documentados (y sus valores predeterminados, si están documentados):

Primero obtenga la Documentación del repositorio de origen.

svn export https://github.com/git/git/trunk/Documentation

o si no tienes svn ,

curl -L https://api.github.com/repos/git/git/tarball/master | tar -xvzf- --strip-components=1 --wildcards --no-anchored ''Documentation/*''

Entrar en el directorio

cd Documentation

Comenzar grep . Tengo dos versiones: una detallada y otra más compacta (es probable que falten detalles). Usaré los nombres de bandera más largos a continuación para (algo) de claridad.

Primero la versión compacta:

grep --initial-tab /
--recursive /
--binary-files=without-match /
--no-filename /
--only-matching /
--perl-regexp /
--null-data /
--regexp=''(?ms)(?:^[a-z][a-zA-Z]+/.[<>()*.a-zA-Z]+::/v+)+?(?:(?:/v|/h+/V+/v))+(?:/v|/Z)''

Para la versión más ''detallada'' simplemente cambie la --regexp= a

(?ms)(?:^[a-z][a-zA-Z]+/.[<>()*.a-zA-Z]+::/v+)+?(?:(?:/v|/h+/V+/v))+(?:/+/v+(?:--/v+.+?--|[^+]/V+(?!::/v))+)*(?:/v|/Z)

que expandido es

(?ms)
(?:
^[a-z][a-zA-Z]+/.
[<>()*.a-zA-Z]+::/v+
)+?
(?:
(?:/v|/h+/V+/v)
)+
(?:
/+/v+
(?:
--/v+
.+?
--
|
[^+]/V+(?!::/v)
)+
)*
(?:/v|/Z)

Y como todo esto se basa en la extracción de expresiones regulares, no hace falta decir que esto puede fallar algún día (si cambian el formato de la documentación del archivo txt ).

Algunos resultados de muestra: tenga en cuenta que no todos tienen valores predeterminados:

core.hideDotFiles::
(Windows-only) If true, mark newly-created directories and files whose
name starts with a dot as hidden. If ''dotGitOnly'', only the `.git/`
directory is hidden, but no other files starting with a dot. The
default mode is ''dotGitOnly''.
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.fsmonitor::
If set, the value of this variable is used as a command which
will identify all files that may have changed since the
requested date/time. This information is used to speed up git by
avoiding unnecessary processing of files that have not changed.
See the "fsmonitor-watchman" section of linkgit:githooks[5].
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 linkgit:git-update-index[1]. True by default.
core.splitIndex::
If true, the split-index feature of the index will be used.
See linkgit:git-update-index[1]. False by default.
core.untrackedCache::
Determines what to do about the untracked cache feature of the
index. It will be kept, if this variable is unset or set to
`keep`. It will automatically be added if set to `true`. And
it will automatically be removed, if set to `false`. Before
setting it to `true`, you should check that mtime is working
properly on your system.
See linkgit:git-update-index[1]. `keep` by default.
core.quotePath::
Commands that output paths (e.g. ''ls-files'', ''diff''), will
quote "unusual" characters in the pathname by enclosing the
pathname in double-quotes and escaping those characters with
backslashes in the same way C escapes control characters (e.g.
`/t` for TAB, `/n` for LF, `//` for backslash) or bytes with
values larger than 0x80 (e.g. octal `/302/265` for "micro" in
UTF-8). If this variable is set to false, bytes higher than
0x80 are not considered "unusual" any more. Double-quotes,
backslash and control characters are always escaped regardless
of the setting of this variable. A simple space character is
not considered "unusual". Many commands can output pathnames
completely verbatim using the `-z` option. The default value
is true.

Answer 3

git config --global -l para variables globales o git config -l para variables de repositorio local

PD: Sé que han pasado 2 años desde que publicaste la pregunta, pero estaba buscando lo mismo y leí esta publicación, así que supongo que los usuarios como yo hubieran querido una solución a su problema y publiqué una respuesta, incluso si Probablemente he resuelto tu problema hace mucho tiempo.