Skip to content

Configuration and remotes

Configuration is read the way Git reads it: the system, global and repository files, a worktree’s config.worktree when enabled, then settings passed in GIT_CONFIG_COUNT and its companion variables; the last value wins. Remotes are configuration too, and the transfer commands use what they describe. The library side is in Configuration and provenance.

Read configuration (girt config get and list)

Section titled “Read configuration (girt config get and list)”

girt config get prints the effective value of a key and exits 1 when it isn’t set. girt config list prints every entry as key=value, lowest precedence first; --show-origin prefixes each with the file it came from.

$ girt config get core.bare
false
$ girt config list --show-origin
file:.git/config core.repositoryformatversion=0
file:.git/config core.filemode=true
file:.git/config core.bare=false
…

Section and variable names are printed lowercased and subsections keep their case, as in Git. A key written without a value, an implicit true, prints as true from get and as the bare key from list.

Change configuration (girt config set and unset)

Section titled “Change configuration (girt config set and unset)”

girt config set writes a key to the repository’s own config file, replacing its last occurrence there or adding it. girt config unset removes every occurrence from that file and exits 5 when there is none, as git config --unset-all does. Neither touches global or system files. The last get above prints nothing and exits 1.

$ girt config set demo.colour blue
$ girt config get demo.colour
blue
$ girt config unset demo.colour
$ girt config get demo.colour

Edits change only the bytes of the entry they touch. Comments, spacing, ordering and unknown variables elsewhere in the file stay exactly as they were.

girt remote list prints remote names, and --urls adds their fetch and push URLs, as git remote -v does. girt remote add adds a remote that fetches every branch into refs/remotes/<name>/. girt remote show prints one remote’s URLs and refspecs from configuration, without contacting it.

$ girt remote add upstream https://github.com/joshka/girt.git
$ girt remote list --urls
upstream https://github.com/joshka/girt.git (fetch)
upstream https://github.com/joshka/girt.git (push)
$ girt remote show upstream
name upstream
url https://github.com/joshka/girt.git
pushurl https://github.com/joshka/girt.git
fetch +refs/heads/*:refs/remotes/upstream/*

List what a remote advertises (girt remote heads)

Section titled “List what a remote advertises (girt remote heads)”

girt remote heads connects to a remote and lists what it advertises, without downloading anything. It takes a configured remote name or a path or URL directly. Annotated tags are followed by a ^{} line with the commit they point at.

$ girt remote heads upstream
c050596ed88f5a60d7f41dbfd80735065ccd05ff HEAD
c050596ed88f5a60d7f41dbfd80735065ccd05ff refs/heads/main
…

Over HTTP(S), remote heads is anonymous; fetch, clone and push use configured credential helpers, including store. SSH remotes are written ssh://[user@]host[:port]/path or [user@]host:path, and girt runs GIT_SSH_COMMAND, core.sshCommand, GIT_SSH or ssh from PATH, in that order. A configured command string runs through /bin/sh, so configuration that sets one must be trusted. Non-OpenSSH variants, percent-encoded SSH URLs, query or fragment parts and ~ paths are refused.