GITWRAPPER(1)

💅 GITWRAPPER(1) — the general commands manual, but make it make sense

okay bestie, welcome to gitwrapper(1) — the little middle-man program that summons the right Git repository server for you. no cap, it's basically the group-chat admin of your Git setup 🫶

---

✨ NAME ✨

gitwrapper — invoke an appropriate Git repository server 💫

---

🌸 SYNOPSIS 🌸

gitwrapper -c ‘git-upload-pack repository-path’

that's it. that's the whole vibe check. two ways in, and both of them are -c plus a command string. iconic behavior honestly 🎀

---

💖 DESCRIPTION 💖

so, storytime 📖 — back in the day, the only Git repository server software you could easily get your hands on was baked directly into git-upload-pack(1) and git-receive-pack(1), which ship as part of the git(1) suite. because of that, most Git client implementations literally compiled in the path and calling conventions that git(1) expected. like, hardcoded. built into the binary. no flexibility, no wiggle room, just vibes and a fixed path 🔥

but times have changed, bestie. on a modern system, the admin might want to run one of several different Git repository servers out there — gotd(8) for example. choices! options! main character energy for the sysadmin 👑

now, you can't exactly go modify every single piece of Git client software typically living on a system — that's not giving practical, that's giving nightmare fuel 😭 — so most authors of alternative Git servers just wrote their programs to use the same calling conventions as git-upload-pack(1) and git-receive-pack(1), so they can be dropped right into their place. slay, honestly 💅

but here's the thing — having drop-in replacements for git-upload-pack(1) and git-receive-pack(1) is great and all, except it essentially makes your system configuration depend on hard-installing brand new programs in /usr. and that leads to so many configuration problems for admins 😩 because maybe they want to install a new Git server without altering the system-provided /usr. (maybe to avoid upgrade problems when a new version of the system gets installed over the old one, for example.) or maybe they've got a shared /usr across several machines and don't want to be placing implicit configuration information into a read-only /usr. literally cannot blame them 🫠

so this is where gitwrapper comes in, and it ate 💅. the gitwrapper program is designed to replace git-upload-pack(1) and git-receive-pack(1), and to invoke an appropriate Git server based on configuration information placed in gotd.conf(5). this lets the administrator configure which Git server gets invoked on the system at run-time ✨. Git repositories that are listed in gotd.conf(5) and exist on the filesystem will be served by gotsh(1). any other Git repositories? those get served by git-upload-pack(1) and git-receive-pack(1) as found in Git's libexec directory — which is /usr/local/libexec/git/ by default on OpenBSD 🐡

---

🦋 ENVIRONMENT 🦋

• GOTD_CONF_PATH — set the path to the configuration file for gotd(8). if you don't specify it, the default path /etc/gotd.conf will be used. default queen behavior 👑

---

🎀 FILES 🎀

configuration for gotd(8) is kept in /etc/gotd.conf. that's the spot 📍

git-upload-pack and git-receive-pack are typically set up as a symlink to gitwrapper, which is not usually invoked on its own. so like, don't come for gitwrapper directly, it's got people for that 🙈

---

🌈 SEE ALSO 🌈

got(1), gotd.conf(5), gotd(8), mailwrapper(8)

(the mailwrapper(8) one is the same trick but for mail. iykyk 💌)

---

⭐ AUTHORS ⭐

Stefan Sperling <stsp@openbsd.org> — thank you for your service 🫡💜

---

💀 BUGS 💀

ngl, the entire reason this program exists is a crock. like, fr fr. instead, a command for invoking a Git server should be standardized, or the Git protocol should be changed to make the path to the program discoverable by Git clients. that's the whole bug report. it's giving "this is a workaround and we all know it" 😭

---

ok that's the whole page bestie, go configure your Git server at run-time and thrive 🌸✨

this little love letter to gitwrapper(1) came from the Debian build, dated $Mdocdate$ — mwah, catch you in the next man page 💋🎀🦋