~stick/dotfiles

dotfiles

stick's configuration files

Background
Install
Usage
Contributing
License

Background

Includes configuration for:

aconfmgr
alacritty
aurman
bash
gdb
git
sway (with swaylock )
tmux
vim (including plugins as submodules)

Also includes a set of scripts and small executables used throughout the configuration (./bin/).

Acknowledgements:

This repository's logo has been shamelessly stolen borrowed from Ícaro Medeiros. Many other sources are linked throughout the configuration files.

Install

My dotfiles are kept in a bare repo on $HOME, as suggested by StreakyCobra and written up by durdn (hat tip @sir@cmpwn.com).

Clone as a bare repository to $HOME/.dotfiles.
Create the dots alias to interact with the repository.
Check out the workstation branch.

$ git clone --bare https://git.sr.ht/~stick/dotfiles $HOME/.dotfiles
$ alias dots='git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'
$ dots checkout stick
$ dots submodule update --init --recursive --remote

NOTE: Performing the checkout will likely fail due to files already in place (.bashrc, .tmux.conf, .vim, etc). You should (back up and) remove the offending files and simply re-run the checkout.

Dependencies

Required

The included sway configuration requires the following packages as dependencies (listings are for Arch Linux; YMMV):

alacritty (terminal emulator; also used for launcher)
i3status-rust (status command for swaybar) (AUR)
otf-font-awesome (used in info bar)
polkit-gnome (PolicyKit integration in gdm and sway)
python-i3ipc (Python library to control sway)
sway (window manager)

Optional

adobe-source-code-pro-fonts (default font)
libpulse (volume control)
playerctl (music player controls)

Usage

Use the dots alias (made permanent in .bashrc) to interact with the repository.

NOTE: The .gitignore has a * rule which matches everything, so you must use -f or --force when adding files or submodules.

I typically use gdm to handle workstation login; it is included in the aconfmgr configuration.

Contributing

Contributors to this project adhere to the Code of Conduct.

I welcome issues, but I prefer pull requests! We follow the trunk-based development model (where your fork is a feature branch). Contributions should use git with discipline.

refs

clone