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.barefalse$ girt config list --show-originfile:.git/config core.repositoryformatversion=0file:.git/config core.filemode=truefile:.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.colourblue$ girt config unset demo.colour$ girt config get demo.colourEdits change only the bytes of the entry they touch. Comments, spacing, ordering and unknown variables elsewhere in the file stay exactly as they were.
Manage remotes (girt remote)
Section titled “Manage remotes (girt remote)”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 --urlsupstream https://github.com/joshka/girt.git (fetch)upstream https://github.com/joshka/girt.git (push)$ girt remote show upstreamname upstreamurl https://github.com/joshka/girt.gitpushurl https://github.com/joshka/girt.gitfetch +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 upstreamc050596ed88f5a60d7f41dbfd80735065ccd05ff HEADc050596ed88f5a60d7f41dbfd80735065ccd05ff 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.