Chezmoi test case for #2818

[EvanCarroll]

Follow up on #2818

I'll just keep this technical here is a test case,

cat <<EOF | podman run -i alpine:3 /bin/sh -

  apk update;
  apk add chezmoi git;

  echo "THIS IS OLD" > ~/.profile;
  cat ~/.profile | sed -e 's/^/CHEZMOI PRE_APPLY:\t/'

  echo "Running chezmoi init"
  chezmoi init "https://github.com/EvanCarroll/dotfiles_chezmoi.git";

  echo "DEBUG: Running - chezmoi apply"
  echo "DEBUG: Let's check out the profile, still old..."
  chezmoi apply; 

  cat ~/.profile | sed -e 's/^/[HOME_DIR POST_APPLY]:\t/'
  cat ~/.local/share/chezmoi/dot_profile | sed -e 's/^/[CHEZMOI_DIR POST_APPLY]:\t/'

EOF

In the above case, when it prints the HOME_DIR POST_APPLY copy, I would expect that to be the actual copy on chezmoi repo.. which is this

• https://github.com/EvanCarroll/dotfiles_chezmoi/blob/main/dot_profile

Now, I can tell what's happening from further investigation, there is a conflicting dotfile which is here

• https://github.com/EvanCarroll/dotfiles_chezmoi/blob/main/private_dot_local/private_share/chezmoi/literal_dot_profile

This is weird though because when I'm on the other machine that I used to create this repo, and I do chezmoi cd; git status it shows "nothing to commit, working tree is clean". So I take it the other machine is in sync, and the ~/.profile there is, as confirmed, the same as the one above at:

• https://github.com/EvanCarroll/dotfiles_chezmoi/blob/main/dot_profile

However, when I do a subsequent chezmoi init; chezmoi apply on the repo in question on another machine the ~/.profile is not (as expected)

• https://github.com/EvanCarroll/dotfiles_chezmoi/blob/main/dot_profile

But instead,

• https://github.com/EvanCarroll/dotfiles_chezmoi/blob/main/private_dot_local/private_share/chezmoi/literal_dot_profile

I only see literal documented here,

The literal_ prefix and .literal suffix can appear anywhere and stop attribute parsing. This permits filenames that would otherwise conflict with chezmoi's attributes to be represented.

And I have no idea how that file got created. I can create a container of the other machine that created these files too to show you what's going on there.

But respectfully while I want chezmoi to the best and least confusing it can be, I'm already back on yadm. So not a threat, I'll help you make it better. I tried to explain the confusion I encountered before I left in the last ticket. I don't understand what's going on here. It's just a UX that's not positive: I can't reason about what's going on and the documentation isn't clear. We're all friends. Take care.

[twpayne]

Thank you for the positive technical follow-up!

What I think is happening here is that chezmoi's source state (in ~/.local/share/chezmoi) is specifying that chezmoi should manage (i.e. change when you run chezmoi apply) files in its own source state. What this means is that when you run chezmoi apply you'll first see ~/.profile updated to the contents as defined by ~/.local/share/chezmoi/dot_profile. However, chezmoi apply also changes the contents of ~/.local/share/chezmoi/dot_profile as it is defined by ~/.local/share/chezmo/private_dot_local/private_share/chezmoi/literal_dot_profile. The result is, understandably, confusing.

I'll write a bit more in a follow-up message, but the tl;dr fix is to tell chezmoi to stop managing files in ~/.local/share/chezmoi with the command:

$ chezmoi unmanage ~/.local/share/chezmoi

This command is the equivalent to running

$ chezmoi cd
$ rm -rf private_dot_local/private_share/chezmoi

Of course, you will need to commit the changes to your dotfiles repo.

[bradenhilton]

@EvanCarroll If I had to guess, you probably ran chezmoi add ~/.local/share/chezmoi{/dot_profile} or similar at some point.

[twpayne]

Some background on the moving parts here, in no particular order:

• chezmoi manages dotfiles, and chezmoi itself is configured through dotfiles, so when chezmoi ends up managing its own dotfiles, weird things happen.
• chezmoi has a special case for handling its config file (typically ~/.config/chezmoi/chezmoi.toml) through the use of config file templates.
• The literal_dot_profile file was almost certainly created by running chezmoi add on one of ~/.local/share/chezmoi's parent directories.

I would like to add a mechanism to prevent chezmoi from managing its own dotfiles (with the exception of a config file template). I'm not sure how to do this 100% reliably (especially as all of the directories that chezmoi uses can be dynamically configured through command line flags), but maybe an error/warning when trying to add any directory with "chezmoi" in it might be sufficient.

[bradenhilton]

Perhaps we could NOP/warn/error on any target whose absolute path starts with the absolute path of the source directory (whatever that is at time of execution)? Changing the source/destination path is sufficiently advanced in my opinion.

[EvanCarroll]

I certainly would not have done this

chezmoi add ~/.local/share/chezmoi{/dot_profile}

However, what I may have done was

chezmoi cd;
chezmoi add dot_profile;
git commit;
git push;

Rather than

chezmoi cd;
git add dot_profile;
git commit;
git push;

That kind of typo is possible.

[twpayne]

chezmoi cd;
git add dot_profile;
git commit;
git push;

That kind of typo is possible.

Good point. I added a test to #2822 to catch exactly this.

[twpayne]

Fixed with #2822.