Skip to content

jcorbin/starter_home

Repository files navigation

How I Manage My Home

I wouldn't really call it "move in ready" yet, but the walls are up.

If you're an intrepid early adopter, head on over to the MOVING guide and start packing!

I use Git with a twist:

  • I've set it up to ignore everything by default
  • I then whitelist what git should care about

Finally use a few other twists around git:

  • $HOME's only remote is a local repository, such as $HOME/home-int
  • $HOME is on a context-specific non-master branch (e.g. patron, personal, server, etc)
  • $HOME/home-int has the remotes you'd expect:
    • Github for the master branch
    • Linode for any personal branches
    • private git server for patron branches

I also use automatic worktree updating on push, as setup by my git-setup-worktree-push script.

All of this allows me to:

  • quickly commit any changes in $HOME before they become forgotten
  • reconciliation (merging, rebasing, etc) so that any conflicts or other artifacts do not break my actual $HOME
  • easily separate public vs private changes without much risk of leaking private details to Github

Git

Much of my workflow as a programmer revolves around managing changes. As such, my git config is one of the parts of my setup that I iterate on the most. The [alias] section is where most of the important parts are.

(Neo)Vim

The only thing I use more than git, is vim (actually neovim.) While I do still have a .vimrc for classic vim, it's under-maintained at this point. Most of my vim config that matters is in .config/nvim/init.vim.

I use vim-plug to manage my neovim plugins (and pathogen for classic vim). I try to keep my vim config cleanly organized using manual fold markers, and by separating out anything beyond simple settings changes into separate plugins.

Basic Shell Setup: .profile, .bashrc, and .zshrc

First off, I'm primarily a Zsh user, but also have to use bash on occasion.

Because of this, there's a clear separation between non-shell specific environment in .profile, and any shell-specific things in that shell's rc file.

There's also a shared .aliases file between bash and zsh (TODO: I've never cared enough about my bash to fragment its rc, probably should get on that).

Rather than manage a monolithic dot file, I keep my .profile and .zshrc fragmented into .profile.d/ and .zsh/rc.d/ respectively.

So that I don't get into a manual numeric-prefixing game, I declare fragment dependencies in comments in each fragment; for example, I could have a file .profile.d/bar:

# after: foo
export BAR_THING="$FOO_THING"

Since the bar fragment depends on the foo fragemnet to define $FOO_THING. There is also a corresponding # before: ... form so that a dependency can inject itself before a dependant.

Dependency and dependant names don't have to actually be concrete files; for example in my .profile.d I have a virtual bootstrap dependant for early fragments such as hostname and locale.

Dependency resolution is done by a simple python script driving a simple for part in ...; do source $part; done loop.

Shell Orchestration: TMux (RIP Screen)

I use TMux for terminal multiplexing; its config is kept in .tmux.conf with an additional include statusline styling.

I do also have mouldering .screenrc from a long time ago.

About

A Decent Starter $HOME

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published