You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the contents of an external_ directory are applied, they are copied as-is, except that executable files are not marked executable in the destination. Given the described effect and use cases of external_ (and in particular its use in including external git repos as chezmoi-managed submodules) it seems like it should preserve the x bit when applying.
To reproduce
$ chezmoi cd
$$ git submodule add https://github.com/tmux-plugins/tpm.git dot_tmux/plugins/external_tpm
$$ ls -l dot_tmux/plugins/external_tpm/scripts # note that most of the scripts are +x
$$ ^D
$ chezmoi apply .tmux/plugins
$ ls -l .tmux/plugins/tpm/scripts # note that none of the scripts are +x
Expected behavior
The executable bit is preserved when applying external_ sources.
Output of chezmoi doctor
$ chezmoi doctorRESULT CHECK MESSAGEwarning version v2.33.1, built by build.opensuse.orgwarning latest-version v2.33.3ok os-arch linux/amd64 (openSUSE Tumbleweed)ok uname Linux thoth.ancilla.ca 6.2.8-1-default #1 SMP PREEMPT_DYNAMIC Wed Mar 22 18:56:06 UTC 2023 (221c28f) x86_64 x86_64 x86_64 GNU/Linuxok go-version go1.19.8 (gc)ok executable /usr/bin/chezmoiok config-file no config file foundwarning source-dir ~/.local/share/chezmoi is a git working tree (dirty)ok suspicious-entries no suspicious entrieswarning working-tree ~/.local/share/chezmoi is a git working tree (dirty)ok dest-dir ~ is a directoryok umask 022ok cd-command found /bin/zshok cd-args /bin/zshinfo diff-command not setok edit-command found /usr/bin/nanook edit-args nano --softwrap -a -wok git-command found /usr/bin/git, version 2.40.0ok merge-command found /usr/bin/vimdiffok shell-command found /bin/zshok shell-args /bin/zshinfo age-command age not found in $PATHok gpg-command found /usr/bin/gpg, version 2.3.8info pinentry-command not setinfo 1password-command op not found in $PATHinfo bitwarden-command bw not found in $PATHinfo dashlane-command dcli not found in $PATHinfo gopass-command gopass not found in $PATHinfo keepassxc-command keepassxc-cli not found in $PATHinfo keepassxc-db not setinfo keeper-command keeper not found in $PATHinfo lastpass-command lpass not found in $PATHinfo pass-command pass not found in $PATHinfo passhole-command ph not found in $PATHinfo rbw-command rbw not found in $PATHinfo vault-command vault not found in $PATHinfo secret-command not set
Additional context
Motivation
I have a number of chunks of configuration that are git-managed in separate repos from . Some, like tpm or zgen, just need to be dropped into ~ somewhere and can be considered read-only from that point onwards, but others, like hypatian-prompt, I actively edit and need to be able to track and commit changes to. Using cm-managed submodules makes this convenient, because it automatically integrates them into cm update/cm apply, and when I have made local edits to them, the changes will show up alongside my other dotfile edits in cm diff.
Workarounds
Use a post-apply hook to fix the permissions
This works, but results in everything showing up as edited outside of chezmoi (because it has been).
Use .chezmoiexternal
This breaks chezmoi add, if you ever plan to add a directory that contains, somewhere in it, an externally-managed repo; for example, if I use .chezmoiexternal to bring in tpm, I then can't chezmoi add .tmux -- I must instead cd .tmux and then add the files I've edited individually. See this discussion for details. Using .chezmoiignore can mitigate this at the cost of not being able to propagate changes back into my cm repo with chezmoi add at all.
Use run_once_after or similar to check out the git repos
I haven't tried this yet, but I suspect based on the described behaviour that it will have similarly bad interactions with chezmoi add as the above, and does not participate in chezmoi diff et al.
Store the git repos somewhere else where they will never be chezmoi added and symlink them into place
This is the least bad workaround I've come up with so far, in that it doesn't create lots of noise in chezmoi status and doesn't break chezmoi add, but it also means I can't use add or diff to manage them; I have to handle them completely separately.
Related Issues
#1106 encountered similar problems (with the same git repo, even!) and ended up solving it with a run_once_after script that clones the git repos but does not manage them in cm.
Post-apply, the gitdir recorded in .git for the submodule is correct in the source directory, but incorrect in the destination directory (because it is relative to the submodule's location). I don't believe there's an open bug for this, but it's also easier to work around.
The text was updated successfully, but these errors were encountered:
Describe the bug
When the contents of an
external_
directory are applied, they are copied as-is, except that executable files are not marked executable in the destination. Given the described effect and use cases ofexternal_
(and in particular its use in including external git repos as chezmoi-managed submodules) it seems like it should preserve the x bit when applying.To reproduce
Expected behavior
The executable bit is preserved when applying
external_
sources.Output of
chezmoi doctor
Additional context
Motivation
I have a number of chunks of configuration that are git-managed in separate repos from . Some, like tpm or zgen, just need to be dropped into ~ somewhere and can be considered read-only from that point onwards, but others, like hypatian-prompt, I actively edit and need to be able to track and commit changes to. Using cm-managed submodules makes this convenient, because it automatically integrates them into cm update/cm apply, and when I have made local edits to them, the changes will show up alongside my other dotfile edits in cm diff.
Workarounds
Use a post-apply hook to fix the permissions
This works, but results in everything showing up as edited outside of chezmoi (because it has been).
Use
.chezmoiexternal
This breaks
chezmoi add
, if you ever plan toadd
a directory that contains, somewhere in it, an externally-managed repo; for example, if I use.chezmoiexternal
to bring in tpm, I then can'tchezmoi add .tmux
-- I must insteadcd .tmux
and then add the files I've edited individually. See this discussion for details. Using.chezmoiignore
can mitigate this at the cost of not being able to propagate changes back into my cm repo withchezmoi add
at all.Use
run_once_after
or similar to check out the git reposI haven't tried this yet, but I suspect based on the described behaviour that it will have similarly bad interactions with
chezmoi add
as the above, and does not participate inchezmoi diff
et al.Store the git repos somewhere else where they will never be
chezmoi added
and symlink them into placeThis is the least bad workaround I've come up with so far, in that it doesn't create lots of noise in
chezmoi status
and doesn't breakchezmoi add
, but it also means I can't useadd
ordiff
to manage them; I have to handle them completely separately.Related Issues
#1106 encountered similar problems (with the same git repo, even!) and ended up solving it with a
run_once_after
script that clones the git repos but does not manage them in cm.Post-
apply
, thegitdir
recorded in .git for the submodule is correct in the source directory, but incorrect in the destination directory (because it is relative to the submodule's location). I don't believe there's an open bug for this, but it's also easier to work around.The text was updated successfully, but these errors were encountered: