HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
RichiH
vcsh
Shell2012–2026
RichiH / vcsh

vcsh

config manager based on Git

Command LineSystems & InfrastructureDeveloper ToolsMobile & DesktopAutomation & Workflows
Explore on GitHubRead Hacker News discussions
23Distinct people
30Mentions
1Explicit recommenders
2.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

config manager based on Git

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I recommend using vcsh[1] to sync your dotfiles between different frequently used machines. This script seems to copy all the files every time you login which can slow down…

tyrion used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year30 dated mentions

Observed mentions: 2012-01-02 19:00:25 UTC to 2026-01-08 00:46:52 UTC.

012342012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC202
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC413
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC413
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC303
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC312
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC312
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC413
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
vcsh - Version Control System for $HOME - multiple Git repositories in $HOME Index 30 Second How-to Introduction Installation Detailed documentation Contact 30 Second How-to While it may appear that there's an overwhelming amount of documentation and while the explanation of the concepts behind vcsh needs to touch a few gory details of git internals, getting started with vcsh is extremely simple. Let's say you want to version control your vim configuration: vcsh init vim vcsh vim add ~/.vimrc ~/.vim vcsh vim commit -m 'Initial commit of my Vim configuration' # optionally push your files to a remote vcsh vim remote add origin <remote> vcsh vim push -u origin master # from now on you can push additional commits like this vcsh vim push If all that looks a lot like standard git, that's no coincidence; it's a design feature. Introduction vcsh allows you to maintain several Git repositories in one single directory. They all maintain their working trees without clobbering each other or interfering otherwise. By default, all Git repositories maintained via vcsh store the actual files in $HOME but you can override this setting if you want to. All this means that you can have one repository per application or application family, i.e. zsh, vim, ssh, etc. This, in turn, allows you to clone custom sets of configurations onto different machines or even for different users; picking and mixing which configurations you want to use where. For example, you may not need to have your mplayer configuration on a server or available to root and you may want to maintain different configuration for ssh on your personal and your work machines. Talks Some people found it useful to look at slides and videos explaining how vcsh works instead of working through the docs. All slides, videos, and further information can be found on the author's talk page. Installation A lot of modern UNIX-based systems offer packages for vcsh. In case yours does not, read INSTALL.md for instructions on installing from sources or even create a package for your system. If you do end up packaging vcsh please let us know so we can document package availability. Detailed documentation For more information, consult the detailed documentation. Contact There are several ways to get in touch with the author and a small but committed community around the general idea of version controlling your (digital) life. IRC: #vcs-home on irc.oftc.net Mailing list: http://lists.madduck.net/listinfo/vcs-home Pull requests or issues on https://github.com/RichiH/vcsh
Read the full README on GitHub

What Hacker News says

4 sources
saidajigumi·Oct 28, 2013
> What do you do when you have to use a computer without your customization? As someone who has used an increasingly customized *nix command-line environment for decades, I'll say that this corner-case occupies a vanishingly small amount of my time. I just doesn't make sense to optimize for it. I currently use zsh, which is frequently not available by default. This implies installing a package, and I don't see how that's any worse for fish. I freely admit that my workflow as a developer vs. (e.g.) a sysadmin provides a greater degree of relative control over my day-to-day working environments. I do have to work in non-customized environments from time to time. I find this no worse than using Someone Else's Keyboard -- maybe there's some clumsiness at first, but you soon get the hang of it. If you switch environments frequently, the sw
Read the rest
itch becomes unnoticeable. That said, I've also put continual effort into portability and ease of deployment of my customizations over the years. I can run one command on a networked host and have my rcfiles land there and be ready to use. This is pretty easy to do with a git-managed homedir repo, especially on a provider like GitHub where you can fall back to grabbing tarball if needed. I currently use vcsh[1] & mr[2] to manage my repos -- for that I use a bootstrap script hosted in an orphan branch of the same repo.[2] An efficient setup process of this type also makes it easy to integrate with provisioning tools, e.g. Puppet, Chef, or even just shell scripts. [1] https://github.com/RichiH/vcsh [2] http://myrepos.branchable.com/ [3] https://github.com/jwhitley/vcsh-root/tree/bootstrap
In Fish shell 2.1
saidajigumi·Sep 5, 2013
I can't say that I've ever had a problem with accidentally running commands in my top-level repo despite many years of running it under git and other VCS'es. That said, using tools mentioned in this thread (esp. vcsh[1] and mr[2]) it's possible to have one's cake and eat it too w.r.t. using git for homedir version control without the worries of accidentally running VCS commands on your homedir. They also allow some real benefits, like the ability to use and deploy subsets of your rcfiles. For example, you could easily create profiles like: "server-side minimal core", "main personal system", "work box with employer-specific stuff". [1] https://github.com/RichiH/vcsh [2] http://myrepos.branchable.com/
In Using GNU Stow to manage your dotfiles

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.