You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Files and directories start with a dot (.) are hidden
Hidden files are often configuration files meant to be read by programs - and only tampered by people who know what they are doing.
Most development tools and platforms today support some level of configuration as code - meaning that the state of the tool can be created from some level of code - usually a hidden file or folder in the root of the repository.
You probably noticed the .github folder in the root of this repository. It holds configuration data for GitHub Classroom (classroom), GitHub Actions (workflows) and I even created my own scope called template I used to copy the state of the template repository to this one.
There's also a folder called .git next to .github You can't see it in the explorer on VS Code. but you can see it if you run ls -a in the terminal. .git contains alle the control files to the git repositories, an it's not likely that you will need to mess around with any of these files (of course there are always exceptions - so we will hack at least one of the files in there later).
But this is why VC Code shows you .github but not .git: Hidden files are for you, as a developer - only .git specifically - is not.
Most often configuration files are written in either yaml or json. But git uses it's own format - salled git config files. Git uses the git config files to store tuples; that is pairs of keys and values. much like environment variables in a Linux shell.
Here's an excerpt of the global.gitconfig file on my computer
Some of the settings I put there myself, some of them are added by plug-ins or extensions I've installed. Some of the settings simply changes the default behaviour of git - if I remove them git still works - only differently. I use the git config to tweak git to my personal liking.
You can see your own global git config file by running:
cat ~/.gitconfig
Git Config is an in-line editor and reader
Git has a subcommand called config. It's an in-line editor/reader. The syntax for using it is:
usage: git config [<options>]
Config file location
--global use global config file
--system use system config file
--local use repository config file
--worktree use per-worktree config file
-f, --file <file> use given config file
--blob <blob-id> read config from given blob object
Action
--get get value: name [value-pattern]
--get-all get all values: key [value-pattern]
--get-regexp get values for regexp: name-regex [value-pattern]
--get-urlmatch get value specific for the URL: section[.var] URL
--replace-all replace all matching variables: name value [value-pattern]
--add add a new variable: name value
--unset remove a variable: name [value-pattern]
--unset-all remove all matches: name [value-pattern]
--rename-section rename section: old-name new-name
--remove-section remove a section: name
-l, --list list all
--fixed-value use string equality when comparing values to 'value-pattern'
-e, --edit open an editor
--get-color find the color configured: slot [default]
--get-colorbool find the color setting: slot [stdout-is-tty]
Type
-t, --type <type> value is given this type
--bool value is "true" or "false"
--int value is decimal number
--bool-or-int value is --bool or --int
--bool-or-str value is --bool or string
--path value is a path (file or directory name)
--expiry-date value is an expiry date
Other
-z, --null terminate values with NUL byte
--name-only show variable names only
--includes respect include directives on lookup
--show-origin show origin of config (file, standard input, blob, command line)
--show-scope show scope of config (worktree, local, global, system, command)
--default <value> with --get, use default value when missing entry
Reading values out of gitconfig
Which files does --local, --global and --system read from respectively?
What's special about these three locations - Why do you think that exactly these locations are used?
Which (one) of the three scope files are inside your repository
Is it version controlled?
You can use the --get switch to git config read out values from everything that git knows from it's config files. Like this:
git config --get user.name
git config actually has three predefined scopes (files) it reads from: --local, --global and --system. When you use the --get switch and don't specify a scope it it read from all scopes and returns the first value match it finds.
You can also use git config to set a value - rather than read it; you simply use the --add switch instead.
If you don't specify a scope it goes to --local if you want it int --global og --system you must say it.
git rev-parse --show-toplevel is a command that returns a string - and in the example above we uset the output from the command as a string - which we concatenate with another string to build the qualified path to the config file.
It's supported in bash - and the concept goes by the name Command Substitution
Aliases are expected default to contain git commands - so the command git is implicitly prefixed to aliases - unless the value starts with an exclamation mark ! - then its a bash command.
Git Config Files
An intro to hidden files and configuration files
.
) are hiddenMost development tools and platforms today support some level of configuration as code - meaning that the state of the tool can be created from some level of code - usually a hidden file or folder in the root of the repository.
You probably noticed the
.github
folder in the root of this repository. It holds configuration data for GitHub Classroom (classroom
), GitHub Actions (workflows
) and I even created my own scope calledtemplate
I used to copy the state of the template repository to this one.There's also a folder called
.git
next to.github
You can't see it in the explorer on VS Code. but you can see it if you runls -a
in the terminal..git
contains alle the control files to the git repositories, an it's not likely that you will need to mess around with any of these files (of course there are always exceptions - so we will hack at least one of the files in there later).But this is why VC Code shows you
.github
but not.git
: Hidden files are for you, as a developer - only.git
specifically - is not.Most often configuration files are written in either
yaml
orjson
. But git uses it's own format - salled git config files. Git uses the git config files to store tuples; that is pairs of keys and values. much like environment variables in a Linux shell.Here's an excerpt of the global
.gitconfig
file on my computerSome of the settings I put there myself, some of them are added by plug-ins or extensions I've installed. Some of the settings simply changes the default behaviour of git - if I remove them git still works - only differently. I use the git config to tweak git to my personal liking.
You can see your own global git config file by running:
cat ~/.gitconfig
Git Config is an in-line editor and reader
Git has a subcommand called
config
. It's an in-line editor/reader. The syntax for using it is:usage: git config [<options>]
Reading values out of gitconfig
--local
,--global
and--system
read from respectively?You can use the
--get
switch togit config
read out values from everything that git knows from it's config files. Like this:git config
actually has three predefined scopes (files) it reads from:--local
,--global
and--system
. When you use the--get
switch and don't specify a scope it it read from all scopes and returns the first value match it finds.You can also use
git config
to set a value - rather than read it; you simply use the--add
switch instead.If you don't specify a scope it goes to
--local
if you want it int--global
og--system
you must say it.Try this
...You've just made an alias!
Run the following commands - one at a time
You can use a fourth level
--file
--file
do?$(git rev-parse --show-toplevel)
do?Run these commands one at a time:
Dive into Command Substitution
git rev-parse --show-toplevel
is a command that returns a string - and in the example above we uset the output from the command as a string - which we concatenate with another string to build the qualified path to the config file.It's supported in bash - and the concept goes by the name Command Substitution
Here's what the man page for bash has to say:
Consequently these two commands does the same job:
You can even include config files in other files
You can include more files in any of the others using the key
include.path
. Dig this!Dublets are allowed - but not supported - what a mess!
--global
! Why?You can add the same key more than once - this can easily lead to undesired situation.
Let's add a a misspelled alias and then add the correct one, and then see what happens:
OK! That went well - except that they are both still three - the bad alias wasn't replaced a new one was merely inserted.
Run:
It's like a stack it read everyting and the last value put in the stack counts.
...you see?
These files aren't wildly complicated and often the easiest way to sort issues is simply to open the files in an editor.
Fix it by running:
Or let's recreate the faulty situation and fix it using
--unset
and--unset-all
Let's run one last test, to learn the read order of the scopes.
That was fun! - let's read and then delete them in the order they are read.
ENOUGH - lets use it.
Except! Did you notice the
!
?Aliases are expected default to contain git commands - so the command
git
is implicitly prefixed to aliases - unless the value starts with an exclamation mark!
- then its a bash command.Dig this!
The text was updated successfully, but these errors were encountered: