Closed vaygr closed 1 year ago
chezmoi doesn't know about git submodules when reading the source state. To chezmoi, the source state is just a normal directory.
Extending chezmoi to understand git submodule structures is something that I don't want to do for multiple reasons:
The whole point of chezmoi is that you can keep all your dotfiles for multiple machines in a single repo. chezmoi provides a huge range of features for controlling exactly which dotfiles are present on each machine, how their contents adapt to the local machine, and ensuring that secrets don't leak. Fundamentally, if you're using chezmoi with multiple dotfile repos, then you're not holding chezmoi correctly.
So, I would instead recommend using something like this instead.
What exactly are you trying to do?
I'm using chezmoi with 2 git repositories, where one is a git submodule of the other. The main benefit is that I can have a small subset of dotfiles synced and available on a specific subset of nodes (e.g. servers) while parent repository that's used primarily on workstations can have symlinks to the files/templates in that "server" sub-repository. That works perfectly.
However when using a more lightweight approach for handling machine-to-machine differences (as described in Without using symlinks), I found out that both
include
andincludeTemplate
don't take sub-repo relativity into account.For example, if I have:
in
~/.local/share/chezmoi/dot_sdots
and this is executed on a node that uses parent git repository, it would look for a template in~/.local/share/chezmoi/.chezmoitemplates
first, then fallback to~/.local/share/chezmoi/
. Same forinclude
.Shouldn't chezmoi look for include files/templates relative to the original repository path (which in the example above would be
~/.local/share/chezmoi/dot_sdots
)?What have you tried so far?
N/A
Where else have you checked for solutions?
Output of any commands you've tried with
--verbose
flagOutput of
chezmoi doctor
Additional context
Add any other context about the problem here.