Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

external_ doesn't respect the executable bit #2964

Closed
ToxicFrog opened this issue May 1, 2023 · 2 comments · Fixed by #2966
Closed

external_ doesn't respect the executable bit #2964

ToxicFrog opened this issue May 1, 2023 · 2 comments · Fixed by #2966
Labels
bug Something isn't working

Comments

@ToxicFrog
Copy link

ToxicFrog commented May 1, 2023

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 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 doctor
RESULT    CHECK                MESSAGE
warning   version              v2.33.1, built by build.opensuse.org
warning   latest-version       v2.33.3
ok        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/Linux
ok        go-version           go1.19.8 (gc)
ok        executable           /usr/bin/chezmoi
ok        config-file          no config file found
warning   source-dir           ~/.local/share/chezmoi is a git working tree (dirty)
ok        suspicious-entries   no suspicious entries
warning   working-tree         ~/.local/share/chezmoi is a git working tree (dirty)
ok        dest-dir             ~ is a directory
ok        umask                022
ok        cd-command           found /bin/zsh
ok        cd-args              /bin/zsh
info      diff-command         not set
ok        edit-command         found /usr/bin/nano
ok        edit-args            nano --softwrap -a -w
ok        git-command          found /usr/bin/git, version 2.40.0
ok        merge-command        found /usr/bin/vimdiff
ok        shell-command        found /bin/zsh
ok        shell-args           /bin/zsh
info      age-command          age not found in $PATH
ok        gpg-command          found /usr/bin/gpg, version 2.3.8
info      pinentry-command     not set
info      1password-command    op not found in $PATH
info      bitwarden-command    bw not found in $PATH
info      dashlane-command     dcli not found in $PATH
info      gopass-command       gopass not found in $PATH
info      keepassxc-command    keepassxc-cli not found in $PATH
info      keepassxc-db         not set
info      keeper-command       keeper not found in $PATH
info      lastpass-command     lpass not found in $PATH
info      pass-command         pass not found in $PATH
info      passhole-command     ph not found in $PATH
info      rbw-command          rbw not found in $PATH
info      vault-command        vault not found in $PATH
info      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.

@twpayne
Copy link
Owner

twpayne commented May 1, 2023

Thank you very much for the perfect bug report, and for thinking through so many workarounds!

This is definitely a bug, and #2966 should fix it.

@ToxicFrog
Copy link
Author

Huzzah! Thank you for the quick fix.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants