Opposite of .chezmoignore (i.e. .chezmoiinclude)?

[triallax]

Before I moved back to Chezmoi, I managed my dotfiles using a simple shell script. This approach had its drawbacks, but one big advantage it had compared to Chezmoi was that dotfiles were "allowlisted" on each machine/OS, rather than "blocklisted" as in Chezmoi. This eliminates the case where I forget to add, say, a Linux-specific directory to .chezmoiignore and then Chezmoi installs it on my MacBook (this has already happened to me a few times since I moved back to Chezmoi).

Is there a way to hijack .chezmoiignore into a .chezmoiinclude of sorts? If not, would you consider adding this feature to Chezmoi?

[halostatue]

If this were to be considered, we would need to figure out precedence (does include get processed before ignore or after; if a file is both ignored and included, what happens; should we error out if both ignore and include files are present?). I’m not sure that it would be widely used and it would be fairly complex.

This might be something that could be grafted onto a #2273-like file, but I’m not sure what that would look like.

[triallax]

Then I'll try to work around it like that and post a comment here later.

[eugenesvk]

but what if I'd like to include just a single deeply nested file? Currently if I !/parent/a/b/c/d.txt while excluding the /parent/**, I get a warning that a etc re not in source state, so I'd need to consecutively exclude/include every path element (as I want to exclude children of every a b c etc)

[halostatue]

That last sounds like a potential bug. Can you open an issue with a reproduction example on this? It feels like chezmoi's path resolution should be smart enough to figure out that /parent/** and !/parent/a/b/c/d.txt should not warn about a, b, and c as long as the final target is d.txt (it feels like chezmoi is comparing each part of a path, rather than just the final path state; I’m not sure how easy that would be to fix).

That said, I’ve been using chezmoi since early 2021 and I haven’t really seen a need for this sort of include file. It could be the simplicity of my use case or a failure of imagination, but this (an include file) feels like the wrong solution.

[eugenesvk]

but this (an include file) feels like the wrong solution.

maybe, I'd be fine with the smarter path resolution, don't specifically need a separate file, the more strict "!exclude trumps everything" should work

[halostatue]

I should explain why I think that an include file is the wrong solution and filing a path resolution bug on this is the right thing to fix your issue.

chezmoi and git are (IMO) closely related. They are both repositories of code (and chezmoi itself builds on source control systems, mostly git) for which you must explicitly opt into managing the files that you want to manage. You don’t do this through an include specification, but through git add or chezmoi add.

The existence of .gitignore (and by extension .chezmoiignore) simplifies ignoring side-effect files (e.g., in most C projects, the .o files are built next to the .c files) preventing them from being added on the next call to git add (because git add is for both adding new files and changes in a file; chezmoi does this somewhat better with chezmoi readd and you have to explicitly use chezmoi merge[-all] to add changes piecemeal).

If chezmoi were a "set and automate" system (like backup programs), then it would make sense to have include and exclude files, but it’s not. That which is wanted is explicitly opted in; everything else is ignored by default, but .chezmoiignore prevents (a) writing files that don’t belong on a particular system and (b) adding files that should not be managed when using chezmoi add.