~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)
waybar

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 workstation
$ 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):

adobe-source-code-pro-fonts (default font)
alacritty (terminal emulator; also used for launcher)
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)
waybar (status bar and system tray)

Optional

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