Teach git clone where repos belong

A tiny shell wrapper that intercepts the boring case of git clone and drops repos into a canonical path. Remove the forced context switch; leave the override path open.

April 17, 20263 min read

unix
tools
shell

Every git clone has a stupid little bureaucratic checkpoint built into it.

You paste a URL into the terminal, and then there's that tiny pause: where am I right now, how is this machine laid out, and where do I want this repo to go? None of that is about the code. It is just filesystem bookkeeping. That is not engineering. That is admin.

I do not want to have that conversation every time.

Pick a rule, let the computer remember it

So I picked a rule and let the computer remember it. GitHub repos live in ~/Development/github.com/{owner}/{repo}. More generally, ~/Development/{repo} is already a huge improvement over chaos, though I like keeping the forge and owner in the path because provenance matters and name collisions are real.

The exact path is less important than the existence of a canonical one.

Two projects with the same repo name but different owners stop being a stupid detective story. I always know where cloned code is going to land. And I no longer have to keep a second, fuzzier mental model of my filesystem around just to avoid dropping repos in random places.

The wrapper does the rest

The shell wrapper is the rest of the trick. I intercept the boring case only: git clone, a GitHub URL, and no explicit destination path. In that narrow case, the wrapper extracts owner/repo from the URL, maps it into ~/Development/github.com/..., shows me the target, asks for a one-key confirmation, creates the parent directory, and then hands off to the real git.

So now I can do this from wherever:

anywhere in your shell

bash

$ git clone git@github.com:someowner/somerepo.git

About to clone into:
  ~/Development/github.com/someowner/somerepo

Proceed? [y/N] y

No nesting a repo inside some unrelated repo because I happened to be standing in the wrong directory. No dumping things into ~/Downloads like a raccoon. No stopping to mentally redraw my filesystem before I can get back to work.

The real win is the context switch

That last part is the real win. The annoyance was never the typing. The annoyance was the forced context switch. I dropped into a terminal because I wanted to work on software, not because I wanted to briefly become a filing clerk. That tiny tax compounds. Worse, it makes the machine feel dumber than it has any right to be.

Unix-y in the good sense, not the costume sense.

A small local tool. It does one thing. It composes with an existing command instead of replacing it. It leaves the override path open: if I pass an explicit destination, normal git behavior wins. Good automation removes repetition. It does not confiscate control.

I especially like the confirmation prompt for that reason. The wrapper is helpful, but not spooky. It shows its work. It tells me where the repo is about to go. Then it asks for a yes.

Division of labor

My current version is zsh-flavored because that is what I use. Fine. The idea is the valuable part. Teach the machine the rule once, and stop re-explaining your directory structure to it forever.

Computers are excellent at remembering boring rules. Humans are better at noticing structure and building things. That division of labor seems obvious to me. The machine can remember where repos go. I'll remember why I cloned it.