andsens/homeshick: dotfiles in git, activated by a line in your rc file

The problem is configuration that does not travel

The framing in the README is about time, not about version control. A Unix configuration is assembled by hand, refined over a long period, and then left behind the moment you sit down at a different machine, where none of that tuning exists. Homeshick exists to move that state through git, so a new machine starts from the same configuration you tuned on the old one. The scope is deliberately narrow: it synchronises dotfiles, it does not manage packages, it does not provision a system, and it has no opinion about your operating system. Two constraints are stated up front and both matter more than they look. The floor is Bash 3 and Git 1.5, which dates the tool's assumptions considerably, and the tool is installed into your own home directory with no root privileges required. That combination makes it viable on a locked-down or shared machine where a system-wide installer is not an option, and it is also the reason there is no installer script: the install is a clone into a path of your choosing, and everything after that is a line in a startup file.

Three entry points, because this is shell functions rather than a binary

The top-level listing explains the architecture better than the README does. There are three sibling files at the root, homeshick.sh, homeshick.csh and homeshick.fish, and there is no compiled program anywhere in sight. That means homeshick is a set of shell functions, and shell functions cannot be shared across shell families, which is exactly why there are three of them. The csh variant is not even a plain function: the README sources it as an alias, because alias is the mechanism csh offers for turning a block of shell into a command. Alongside those sit bin/, lib/, completions/ and test/. The completions directory is a statement that this is meant to be a command you type, not a script you run once, and the test directory alongside a lint and test badge in the README header tells you the project has automated checks rather than manual testing by hand. So the shape of the repository is: three shells supported explicitly, a library directory for shared logic, a completion layer, and tests. Any workflow that assumes a single POSIX implementation would be wrong about this project.

Installing means a clone to a fixed path and three rc edits

The whole install is one clone, and the path matters because the rc lines reference it literally:

git clone https://github.com/andsens/homeshick.git $HOME/.homesick/repos/homeshick

Because the path is hard-coded into the startup lines, pick it once and do not move it later, or you will be editing rc files again. Then activate it per shell family, which the README gives as three separate appends:

# from sh and its derivates (bash, dash, ksh, zsh etc.)
printf '\nsource "$HOME/.homesick/repos/homeshick/homeshick.sh"' >> $HOME/.bashrc
# csh and derivatives (i.e. tcsh)
printf '\nalias homesick source "$HOME/.homesick/repos/homeshick/homeshick.csh"\n' >> $HOME/.cshrc
# fish shell
echo \n'source "$HOME/.homesick/repos/homeshick/homeshick.fish"' >> "$HOME/.config/fish/config.fish"

Run only the lines for the shells you actually use; each appends rather than replaces, so running them twice gives you two activations. What you should see afterwards is a homeshick command in a new shell of that family, with completion available. Note what the README does not provide: any command to create, push or restore a dotfile repository. The install path is complete and explicit, the workflow path is not, and that gap is the reason the wiki exists.

Multiple repositories is the part that distinguishes it

Most dotfile arrangements are a single repository, which works until you want somebody else's configuration in the same tree. Homeshick states that it can handle multiple dotfile repositories, and gives the example of installing a larger framework such as oh-my-zsh, or a set of emacs or vim plugins, alongside your own customisations without clutter. That is the design decision worth evaluating, and it is a different one from storing everything in one repository. A single-repository approach keeps related files together and gains atomic commits across all of them, but it means you vendor third-party content into a repository you also edit, and every upstream change arrives as a merge rather than as a tracked unit. Multiple repositories keep provenance obvious and let you pin each one, at the cost of more moving parts and no single commit that describes your whole machine. Homeshick takes the second option deliberately, which is why the tool is built around a command for operating on repositories rather than around a repository. The README does not describe the state model, so if your question is how a partially restored machine behaves, that is a wiki question.

Pushes in August 2026, newest release tag from April 2023

This is the fact to sit with before choosing the tool. The repository is not archived and the last push was on 2026-08-28, so work is landing. The newest release is v2.0.1, tagged on 2023-04-14, with v2.0.0 from 2020-05-13 and v1.1.0 from 2018-06-04 behind it. So the default branch is more than three years ahead of any tag, and the release history stopped while the commits continued. That is a coherent pattern for a mature tool whose changes are small, and it is also exactly the pattern that makes an upgrade decision hard: there is no versioned artefact to pin to, so pinning means pinning to a commit. Two things soften it. The README documents a testing branch for trying unreleased work, which tells you unreleased is a normal state here rather than an accident. And the project has a CONTRIBUTING file, an editor config, a development container directory and a lint and test badge, which describes a project with a working process rather than a hobby patch. The licence is MIT, and for a tool whose whole output is lines appended to your shell startup files, that is the permissive part.

What the README will not tell you: whether it copies or links

There is a wiki page on symlinking and another on automatic deployment, and neither is described in the README beyond the link. That matters more than it sounds, because for any dotfile tool the single most consequential behavioural question is whether your live configuration file is a link into the repository or a copy of it. A link means an edit on one machine changes the repository file and the relationship stays intact; a copy means a program that rewrites the file in place can break the connection without warning, and an edit made directly in your home directory will not travel. Every user of this tool has a preference on that point, and the README does not state which one homeshick implements or how it fails. The same applies to deployment: the automatic deployment page implies the tool can place files on a new machine for you, and the README describes no such command, so the hand-run install in this article is the only part that is documented. The alternative to homeshick is not a competing tool, it is the manual arrangement it replaces: a git clone of your own dotfiles, hand-made links, and hand-edited rc files per shell. What homeshick adds to that arrangement is three shell families handled for you, completion, and a command surface for working with more than one repository. What it does not add is documentation in the repository itself.

Editorial conclusion

Adopt homeshick if you want your shell configuration to travel with you and you use more than one shell family, because the separate sh, csh and fish entry points are the part no single-repository clone gives you. Skip it if you need automatic deployment or a documented symlink policy, since both live on wiki pages the README only links. Before you rely on it, check two concrete things: confirm your shell meets the stated floor of Bash 3 and Git 1.5, and check whether your clone sits ahead of the v2.0.1 tag dated 2023-04-14, because the last push here was 2026-08-28 and the two dates are three and a half years apart. If that gap bothers you, the testing branch is the documented way to see unreleased work.

Frequently asked questions

Official sources

1. andsens/homeshick on GitHub
2. Issues
3. License: MIT
4. README
5. Releases