[HN Gopher] A Way to Manage Dotfiles
___________________________________________________________________
A Way to Manage Dotfiles
Author : bminusl
Score : 29 points
Date : 2021-05-12 19:31 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| andsens wrote:
| Just throwing my solution for dotfiles synchronization into the
| mix as well here, homeshick: https://github.com/andsens/homeshick
|
| Maintained for 8 years now, 1.7k stars, only needs git >=1.5,
| bash >=3, and no root access to install.
|
| It's well tested, stable, and super hackable to fit your needs.
| uneekname wrote:
| I like the bare repository approach here. I've been using
| symbolic links to version control my dotfiles with git.
| poidos wrote:
| I do the same using `stow`, and like it a lot.
| lefrenchy wrote:
| I gave it a quick glance but didn't understand, how is OP's
| link managing it instead of symbolic links?
| [deleted]
| bminusl wrote:
| Files are tracked by a bare git repository, e.g.
| `~/.dotfiles`.
|
| The trick is to use the combination of --git-dir and --work-
| tree git options. An alias can be defined to simplify the
| process: `alias dotfiles='/usr/bin/git --git-
| dir=$HOME/.dotfiles/ --work-tree=$HOME'`.
|
| `dotfiles` can be used as you would use `git`, e.g.:
|
| - `dotfiles add <file>`
|
| - `dotfiles commit [options]`
| yjftsjthsd-h wrote:
| By telling git to use `--work-tree=$HOME`, they tell git to
| _directly_ work on the files in their home directory; no
| symlinks needed.
| DiabloD3 wrote:
| I do a similar thing, but with dotbot instead
| https://github.com/anishathalye/dotbot
| blissofbeing wrote:
| I would highly recommend zero-sh[1] for those looking for a
| consistent simple tool to manage dotfiles on a mac.
|
| 1. https://github.com/zero-sh/zero.sh
| twp wrote:
| Bare git repos are fine for starting, but you quickly hit limits
| if you want to use your dotfiles on different machines, e.g.
| share your .zshrc config between Linux and macOS.
|
| A comparison of popular dotfile managers:
|
| https://github.com/twpayne/chezmoi/blob/master/docs/COMPARIS...
| redis_mlc wrote:
| First world problem.
| josephscott wrote:
| I've been happy with https://yadm.io/ to manage dotfiles.
| sneak wrote:
| I sync a directory of dotfiles across my workstations using
| syncthing. The .bashrc and .profile simply do:
| for FN in ~/.paths/sneak-sync/bashrc.d/*.sh ; do
| source $FN done
|
| Then updates (by adding or removing files to these directories)
| propagate to all my workstations. I have machine-specific ones,
| too, that also sync but aren't included due to differing
| hostnames.
| [deleted]
| NetOpWibby wrote:
| Wow, that's awesome.
| podiki wrote:
| Personally, I use git [0] along with GNU stow [1], combined with
| making the files directly from a literate Readme.org (e.g. [2]).
| I sync this repository between machines to update files, and when
| I make changes in the org-mode Readme file it automatically
| generates the new file. There are ways to pull in changes made to
| that file directly, but haven't needed to do that. My repo
| doesn't walk you through it completely, but I think is pretty
| straightforward. If you want to see it in action along with a few
| links and pointers, do take a look at [0]. I really like having
| it all together in one place, and with org-mode everything is
| very (human) readable.
|
| [0] https://github.com/podiki/dot.me
|
| [1] https://www.gnu.org/software/stow/
|
| [2] https://github.com/podiki/dot.me/blob/master/x11/README.org
| dannyobrien wrote:
| This is beautiful. Thank you for sharing it.
|
| (I use GNU Stow too, though have not thought to create a
| literate version of my scripts and hacks.)
| CGamesPlay wrote:
| I never liked the git bare repository approach, because it's each
| to accidentally add files to it that you don't intend (if you
| forget to run git init in a new project directory; or if some
| code generator decides to "re-use" your existing git repository).
| I prefer the symlinks approach, but I never liked how all of the
| symlinks managers tend to leave broken symlinks all over the
| place.
|
| That's why I created my own solution, which maintains a state
| file in the repo, so doing something like deleting a config file
| or switching a git branch doesn't result in a bunch of broken
| symlinks lying in your system.
|
| https://github.com/cgamesplay/dfm
| tdfirth wrote:
| I've been using this bare repository approach for a while. I
| forget where I first saw it, I'm pretty sure it was on HN but it
| was not this project. I do like it, but I have a few minor
| issues.
|
| The first is that I have a habit of running `git add .` when I'm
| working on source code, and as a result I have accidentally added
| my entire home directory to the bare repo more than once... Easy
| enough to undo but a bit inconvenient. `dotfiles add -u` is the
| safe option, or just be explicit about which files you are
| staging.
|
| The second issue is the 'branch per machine' approach, which I do
| use. I have two machines I use regularly, and a third
| occasionally. There are some bits of config (e.g. for vim) that
| are shared across all the machines, while other bits are not. If
| I use one machine for a while, then I end up with lots commits
| that I need to cherry pick when I next use another machine.
| Depending on how long it has been, this can be a bit of a faff.
|
| Finally, because there is no clear mainline branch, you have to
| pick commits to/from any of the branches. If you are
| undisciplined like me, then this will leave you with a 'three way
| ahead and behind' scenario at some point.
|
| Anyway, I like the approach overall. If anyone has a suggestion
| to ease those pain points I'm all ears.
| bewuethr wrote:
| I, too, saw this approach on HN first - here:
| https://news.ycombinator.com/item?id=11071754
|
| I combined the bare repo approach with a per-machine custom
| branch approach described in
| https://www.anishathalye.com/2014/08/03/managing-your-dotfil...
|
| The idea is that you have the shared configuration in one repo,
| and at the end of each config file, you include a local
| version. The local versions live in a separate repository and
| use a separate branch for each machine.
|
| For example, at the end of .bashrc, you'd have
| if [[ -r $HOME/.bashrc_local ]]; then .
| "$HOME/.bashrc_local" fi
|
| and so on, for each config file. My general dotfiles repo is
| public here, if you want to take a look how I did it for the
| tools I use: https://github.com/bewuethr/dotfiles
|
| This still isn't ideal. For example, I use Git submodules for
| Vim plugins in the shared repo - but maybe I don't need all of
| that on my Raspberry pi. I feel like at some point, a config
| file based solution could be better; or using a tool such as
| https://yadm.io/, which is using bare repos under the hood.
| tdfirth wrote:
| Yes that comment is where I first saw it, thanks for
| reminding me.
|
| Thanks for those pointers and the link to your dotfiles too.
| I will check that out and maybe steal a couple of ideas!!
| away_throw wrote:
| I have a `.gitignore` file with `*` in it to ignore all files,
| so I explicitly type `dotfiles add --force`.
| andypea wrote:
| I've found that a simple dot_files directory that is sync'd via a
| public git repository [0] works well for me. When I'm on a new
| machine all I need to do is clone the repository and run `ln -s
| ~/dot_files/bash/bashrc ~/.bashrc`. The bashrc file then takes
| care of everything else.
|
| It might not work for every program out there, but it does for
| the small number that I use.
|
| [0] https://github.com/andypea/dot_files
___________________________________________________________________
(page generated 2021-05-12 23:01 UTC)