Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Add Feature: Local Customizations Folder (to simplify maintenance) #846

wants to merge 2 commits into


None yet
3 participants


Zsh configuration is very personal. The way "oh-my-zsh" deals with customizations has created an explosion of pull requests some of which are probably too narrow to be in the main repo. This is a maintenance burden. Imo, only generic functionality should be added to this repo - not personal adjustments and tweaks.

One solution

Allow users to make tweaks outside of the repo. This will deincentivize fork/pulls for personal changes.

In this pull I added the concept of 'local customizations'. Instead of adding tweaks to ~/.oh-my-zsh you can instead add them to ~/.zsh. You can then separately track this folder in a personal repo. I added mine to my dotfiles repo, for example.

This is backward compatible with the /custom folder, but imo we should phase that idea out. Also, adjustments in the ~/.zsh folder have precedence over those in /custom.


sorin-ionescu commented Jan 20, 2012

Keeping customisations outside of the repository is a bad idea. The best way to deal with personal changes useless to others is to ask people in the README to not open frivolous pull requests in the first place and to deny the pull requests of those who have not bothered to read it. The Homebrew project handles pull requests quite well.

Any reasons for why it's a bad idea?

I don't think it makes sense for there to be 1000 themes in the repository. Further, the custom folder remains untouched in the main repository anyway. It's not like we're merging upstream changes into our personal custom folder. So, if custom is a special folder already, why not pull it out and make it easier to track in another repository?

Also, by leaving it in the repo your personal history is mixed with general history.

I'm not seeing why this is better at this point.


sorin-ionescu commented Jan 26, 2012

In my fork while working on #377, I have got rid of custom, lib, and many other folders. It's not necessary to use a plethora of filesystem folders to manage your Zsh configuration when it's already managed by the best tool available: Git.

Take five minutes to learn the Git merge strategies, and you will have no problem managing your changes with upstream.

@sorin-ionescu Your remarks are unreasonably condescending. I know how to use git, you are missing my point.

It sounds like you'd prefer to have no custom folder, since we can simply make changes directly and use git to merge. You're right, but I think you're forgetting a few use cases:

  • What if I have private information in my scripts? Should I just throw it in the public repo?
  • What if I want to be sure that I'm only overriding the oh-my-zsh core, not changing it?
  • What if I want to add my customizations to another repo without dealing with submodules?

I'm not hearing any reasons why we shouldn't at least support an external location. This is a minor patch, and enables some use-cases that are more difficult otherwise. I think a customization folder makes sense - I just don't think it should be in the core if we do one (but my patch allows both).

I think we should have a standard custom folder to support case-2, and it should be external to support case-1. Further, by making it external, I can easily add only my adjustments to another repository, case-3.

EDIT: I understand there are ways to accomplish these things with pure git. For instance, for the private info I could submodule another repository for my zsh-only private info. This adds unnecessary complexity though - especially when we're already submoduling 'oh-my-zsh' in a 'dotfiles' repo. Just because we can do this with git, doesn't mean we always should imo.


sorin-ionescu commented Jan 26, 2012

I do not have a superiority complex, in fact, I dest it. I should have chosen my words about learning to use Git more carefully, which were not aimed at you in particular, but members of the general public that invent all sorts of directory hierarchies just to avoid using Git who might read this issue.

  • Should you have private information in a public repository? No. Should you have private information in a private branch or a private repository? Absolutely.
  • How is overriding instead of editing helpful? You're making your shell startup slower. Make OMZ adapt to your needs. Do not adapt your needs to OMZ.
  • I am unsure to what submodules you are referring and where you think you need them.

That said. Whatever works for you, use it, but, it should not be imposed on everybody. OMZ should be simple — the basic minimum configuration necessary to get Zsh converts off the ground. It should not include every feature to support every workflow under the sun.

At the end of .zshrc, it says, 'Customize to your needs.' Users should do so.

I understand your general sentiment. For me it's quite simple, if OMZ is giving users a standard place to put customizations (custom), it makes sense to put that place outside of its repo.

If, instead, this isn't a goal, then the whole custom folder idea should be dropped - changes can be made directly (to the plugin folder for instance), as you're suggesting.

These two seem mutually exclusive. This patch is merely an extension of the current choice.

You're right, to each their own - I have my fork already. This patch, however, makes sense for everyone if OMZ is sticking with the 'customization' bits.


robbyrussell commented Apr 8, 2013

@thedeeno Care to rebase and send over again? Apologies for the latency


robbyrussell commented Apr 24, 2013

WIll close for now.. resubmit when you get a chance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment