[question] Each program's settings as submodule

[marcosrdac]

Hello!

I have my dotfiles structured, but sometimes I am at new computer and I would just like to install my vim settings in there. As I do not want to download all my dotfiles, I have another git repo for my vim configuration files.

I was wondering if I should do this to all my program configs (i.e. submodule each folder in my ~/.config folder). Am I crazy? Do you think I can integrate this workflow to dotbot? I would really like to know what kind of problems I could be running into for doing that, if you know any of it.

Also, thanks for dotbot! It's amazing to know that my problem was already solved by you. Congratuations!

[etkeys]

My two cents (plus tax where applicable)

sometimes I am at new computer and I would just like to install my vim settings in there

When I migrated to dotbot, I faced this problem as well. I have a handful of machines that require their own specific programs and configurations. Even when I start a fresh VM, there are a core set of files that I want: vim, bash, and a few core programs. Someone here, I forget who, and the dotbot docs suggest that you can use different install + install.conf files to manage multiple machine configurations. For me, this became too much to keep track of and also would've created a repo that may have been larger than what I wanted.

So I've followed the advice that @anishathalye uses and has offered to others before. I now have two repos that contain the core/"common" files that I would need on pretty much any machine and a second repo for machine specific files where each machine has its own branch. You could go this route as well. I've even got some of my other repos for scripts and things as submodules so they can be automatically installed on new machines.

Also look into using git clone with the --branch, --depth, --single-branch, and --shallow-submodules options to further reduce the amount data cloned by limiting how much of the history to copy. DISCLAIMER I've only used --branch option before so I don't know how pushing new commits with the additional options will be affected.

I was wondering if I should do this to all my program configs (i.e. submodule each folder in my ~/.config folder)

looks at own ~/.config directory

I've got at least 30 subdirectories. Of those, I'm probably tracking more than I should. They're all relatively small in their own right so managing them as separate submodules would be too much effort. It's easier for me to manage them as separate branches in the machine specific repository and just cherry pick the commits across branches if I needed changes on more than one machine.

[eengstrom]

Without trying to pull the "greybeard card", I've been maintaining my config files in some form of SCM since long before dotbot, and well before git even (anyone remember rcs?), which is to say I've tried a lot of different approaches, and in the end, I've always reverted back to additional host- or distro-specific conditional configuration blocks into my shell config files (e.g. if [[ $(hostname) == foobar ]]) and host- or distro-specific versions of config files for things like tmux (e.g. ~/.tmux-{linux,darwin}).

Why? In the end, I found it was easier to maintain cross-platform similarity by using conditional blocks or alternative versions of files loaded only in certain cases than to maintain multiple repositories. Inevitably, I would find something I wanted on one system that I forgot to copy over from another, so back to a single source for all platforms/hosts. This has worked well for me while simultaneously working on Linux, Solaris, Windows (cygwin or wsl), and MacOS.

For example in my current dotbot.yml, I have:

    ~/.gitconfig-local:
      path: ~/.gitconfig-${DBOT_TARGET_DISTRO}
      if: '[ -n "$DBOT_TARGET_DISTRO" ]'

And then in my ~/.gitconfig, I can simply:

[include]
  path = ~/.gitaliases
  path = ~/.gitconfig-local

Note that to make that work, I set DBOT_TARGET_DISTRO in my wrapper script around dotbot:

# This variable is used in the `dotbot.yml`.  If not set, default to `uname`:
export DBOT_TARGET_DISTRO=${DBOT_TARGET_DISTRO:-$(uname | tr '[A-Z]' '[a-z]')}

[marcosrdac]

Thank you, @etkeys and @eengstrom! Your experiences are really valuable to me. I am sure I'm studying those git commands I am currently not aware of, @etkeys. They will surely be useful to my workflow. I believe I am mainly implementing @eengstrom's solution. I started doing part of it today, and it was pretty easy to follow in that direction. I also did not know I could use environment variables inside the yaml so easily. Awesome, guys!

[strazto]

Personally, I use a variation on

https://github.com/anishathalye/dotbot/wiki/Tips-and-Tricks#how-can-i-have-different-groups-of-tasks-for-different-hosts-with-different-configurations - The more complicated option.

It's flexible enough to cover pretty much everything I need