chezmoi2: Contributors, please help with beta testing

[twpayne]

With #654 merged, chezmoi version 2 is now ready for beta testing. I'd really appreciate it if you could test it on your machines. At the moment, this requires you need to be familiar with Go development to build and install it locally. Packages, snaps, etc. will follow later.

Quick notes:

• You should not need to change anything in your source state. Note that when you run chezmoi2 apply for the first time your run_once_ scripts will run again.
• The goal of chezmoi2 is to enable some new features (e.g. chezmoi2 status) and fix various corner-case bugs that were hard to fix with chezmoi1's architecture. Even though chezmoi2 is a complete re-write internally, to the end user, chezmoi2 is not radically different to chezmoi1.
• Read a rough draft of what's changed.
• See the v2.0.0 milestone for individual issues.
• Right now it's in a separate subdirectory, install it by checking out the master branch and running go install ./chezmoi2.
• It should be safe to use, but please use chezmoi2 diff and/or use the --dry-run option to check changes before you apply them.
• The separate chezmoi2 directory and command name are temporary: eventually chezmoi2 will replace chezmoi1.

Specific ways to help:

• Please install and run chezmoi2 and report anything that seems strange or suspicious in this issue, please don't open new issues yet.
• There are a lot of integration tests in chezmoi2/testdata/scripts. More tests are very welcome!
• Please prefix PRs that affect chezmoi2 with the string chezmoi2:.

What happens next:

• chezmoi2 gets tested a bit more, hopefully by you, to shake out the initial bugs.
• Once chezmoi2 seems mostly stable, I'll update the release processes to produce beta releases for wider testing.
• Once the beta has been more widely tested, chezmoi2 will replace chezmoi.

cc @benmezger @Grimler91 @felipecrs @fwsmit @Legion2 @zb140

[zb140]

I've installed chezmoi2 and things seem to be going pretty well. Here's a couple of things I've noticed after my first chezmoi2 apply:

• Is the chezmoi secret subcommand permanently gone? I've been using it as part of my secret caching scheme to work around the perf issues in 1password. Specifically, I'm caching secrets in keepass and storing the keepass db password in the OS keyring (which gets unlocked when I sign into the computer). Then I use a shell alias to do chezmoi secret keyring get --service secret_cache_pw --user zb | chezmoi apply to apply dotfile changes. I'm sure I can find a workaround if needed.
• As discussed in Symlinks not portable between OSes #959 , I currently have a symlink template in dot_config/nvm/symlink_init.vim.tmpl. Every time I run chezmoi2 apply ~/.config/nvim, I get a warning saying: .config/nvim/init.vim has changed since chezmoi last wrote it, overwrite [y,n,q,a]?. Even if I pick y, the next apply will give the same warning.
  • Side note: ~ expansion (Expand ~ in input paths #963) is working so well I didn't even notice I was using it 😄
• chezmoi2 diff has a lot of stuff like this in the output. It doesn't seem to be doing any harm, though.

  diff --git a/Documents/PowerShell/profile.ps1 b/Documents/PowerShell/profile.ps1
  new file mode 120000
  index 0000000000000000000000000000000000000000..8f7f5d41d95dcac26d6c0c96cca85fe54b752b0f
  --- /dev/null
  +++ b/Documents/PowerShell/profile.ps1
  @@ -0,0 +1 @@
  +..\..\.config\powershell\profile.ps1
  \ No newline at end of file

I haven't started digging into these yet but I'll have a look and report back.

Edit: I think the second two issues are actually related. I forgot that ~/Documents/PowerShell/profile.ps1 is itself actually a symlink, and so are the other files producing similar diff output. So I think maybe the diff algorithm is messing up for symlinks? I'll keep digging.

[zb140]

Ok, it turns out the symlink issues are actually just a side-effect of #959 being fixed. My existing symlink_ files all have host-specific path separators in them, which is causing chezmoi2 to think they're different from the actual symlinks it created. As we discussed in the comments over there, it's easy enough to remove and readd them, so it's not a big deal.

Everything else I've tried so far has Just Worked, but I'll keep playing with it. I'm particularly excited to try out the new pre_ and post_ script stuff because I just happen to be working on some automatic setup scripts right now.

[zb140]

One last thing for tonight: when I make a change to a run_once_ script and then chezmoi2 apply, I get a prompt like this one: <script> has changed since chezmoi last wrote it, overwrite [y,n,q,a]?. It would be nice to be able to suppress this prompt and just always rerun changed scripts. It would be especially nice if that didn't make it automatically overwrite other changed files too 😄 I looked around a little bit for something like this and didn't see anything, but it's totally possible that I missed it.

I've also just discovered while writing this that if I create a run_ script, everything works as normal on the first chezmoi2 apply, but on subsequent apply calls I always get the same prompt as above, even if I haven't changed the script. That seems like it's probably not supposed to be that way. I'll look into it tomorrow after I've had some sleep 😄

[fwsmit]

For those uninitiated on how to build go binaries,

cd chezmoi2
go build

I haven't found any bugs yet, but I'll keep you updated!

[twpayne]

Thanks for the testing @zb140 and @fwsmit!

One last thing for tonight: when I make a change to a run_once_ script and then chezmoi2 apply, I get a prompt like this one: <script> has changed since chezmoi last wrote it, overwrite [y,n,q,a]?.

This should be fixed with 2a60643.

[zb140]

Yep, that totally fixed it, thanks! Nothing new to report today. I'll probably have a few test script updates for Windows to share tomorrow.

[fwsmit]

I noticed a few things about chezmoi2 today

chezmoi2 apply is a lot slower than chezmoi1

❯ time chezmoi2 apply
chezmoi2 apply  0.09s user 0.03s system 39% cpu 0.301 total
❯ time chezmoi apply
chezmoi apply  0.02s user 0.02s system 168% cpu 0.026 total

It went from 0.026s to 0.3s. I think chezmoi2 does some more on apply, but it can probably be improved.

file has changed, do you want to overwrite?

When using both chezmoi1 and chezmoi2, I sometimes get the message
somefile has changed since chezmoi last wrote it, overwrite [y,n,q,a]?
This is probably not an issue when chezmoi2 is actually released, but I'll still say it.
The options here are also a bit confusing. "y" and "n" I understand, but I don't get what "q" and "a" do. Abort and quit? When doing "a", the files is still overwritten. I would suggest leaving it to y and n, and maybe using a default n, like [y/N].

ctrl-c in prompt

When getting the above mentioned prompt, if you press ctrl-c you get something like this

.vimrc has changed since chezmoi last wrote it, overwrite [y,n,q,a]? chezmoi: EOF%

This messes up the shell output, until you do stty sane.

-k always succeeds

When doing a chezmoi apply with -k (keep going), it will always exit with 0. I think it's better if you return an error code anyways, if you come across any.

chezmoi2 apply isn't non-interactive anymore

As mentioned in #992, I automatically apply files from vim. With chezmoi1 this didn't require any interaction, but now it does. You have to specify --keep-going and --no-tty to make it non-interactive in vim (vim apparently doesn't provide a tty to shell commands). I would suggest adding an option like --overwrite=[false/true] to make it non-interactive again.

Come to think of it, most of these issues are with the overwrite functionality added in chezmoi2. I think this change can be confusing for old and new users and could potentially break things. I didn't check if it's possible now, but I would definitely recommend adding an option to disable this feature.

File permissions not correct

After adding something to the file /usr/share/chezmoi/dot_vimrc, and applying the changes with chezmoi2 apply, the permissions changed from 644 to 666. chezmoi1 detects that the permissions have changed, so a chezmoi apply fixes it. Chezmoi2 diff, however, doesn't seem to detect this specific change (from 666 to 644). Adding a +x to the destination file is detected by chezmoi2.

Edit: Added some more things

[twpayne]

Thank you @fwsmit for this awesome testing! Really appreciated. Thank you.

In no particular order:

file has changed, do you want to overwrite?

Hopefully fixed with 7ecad8c. This makes the prompted choices more explicit, and still allows the user to use abbreviations (e.g. y for yes).

ctrl-c in prompt

Should be fixed with b971531. It's a bit less efficient but should restore the user's terminal under more circumstances.

-k always succeeds

Should be fixed with 4682cce.

chezmoi2 apply is a lot slower than chezmoi1

I added 2c06aba but this doesn't solve the problem, it's just a step along the path.

File permissions not correct

This is great feedback and challenges the assumptions that chezmoi2 is making. tl;dr chemzoi2 only checks that permissions are correct with respect to the user's umask.

[fwsmit]

file has changed, do you want to overwrite?

Hopefully fixed with 7ecad8c. This makes the prompted choices more explicit, and still allows the user to use abbreviations (e.g. y for yes).

Yes that makes it a lot more clear. An option for diffing the two files would be a great addition. This would need to bring up a pager with the diff, and when you exit you can make the choice again.

ctrl-c in prompt

Should be fixed with b971531. It's a bit less efficient but should restore the user's terminal under more circumstances.

The terminal isn't messed up after ctrl-c anymore, so that's great! Still, the weird chezmoi: output stays.

-k always succeeds

Should be fixed with 4682cce.

👍

chezmoi2 apply is a lot slower than chezmoi1

I added 2c06aba but this doesn't solve the problem, it's just a step along the path.

The apply times I showed above were for when there were no changes to be applied. Chezmoi2 diff isn't actually slower than chezmoi1, so could you maybe just test if there is a difference and then apply? Or are there other things to do as well?

File permissions not correct

This is great feedback and challenges the assumptions that chezmoi2 is making. tl;dr chemzoi2 only checks that permissions are correct with respect to the user's umask.

I don't really get how comparing to the umask works, but wouldn't it be easier to just check if permissions1==permissions2?

where is the pager?

I see the option --no-pager in the chezmoi diff --help output. How do I get chemzoi to show me a pager with the diff output?

[JustinGrote]

@twpayne to get broader support, why not just post the compiled "nightlies" for commits to the github actions artifacts? I can PR an update to your github actions to enable that if you're willing.
https://docs.github.com/en/actions/guides/storing-workflow-data-as-artifacts

[twpayne]

@JustinGrote, yes, a contribution to add nightlies would be fantastic :)

This initial release of chezmoi2 was deliberately targeted at a few people because there were certainly going to be a few glaring bugs, missing features, and oversights, and I didn't want to be overwhelmed by lots of users hitting and reporting the same problem. I'm really grateful to @zb140 and @fwsmit for their front-line testing and reporting what they found here.

Adding nightlies is the next logical step to make chezmoi2 more widely available to the next layer of kind testers, and I'd very much appreciate a PR that adds this :)

[twpayne]

file has changed, do you want to overwrite?

Hopefully fixed with 7ecad8c. This makes the prompted choices more explicit, and still allows the user to use abbreviations (e.g. y for yes).

Yes that makes it a lot more clear. An option for diffing the two files would be a great addition. This would need to bring up a pager with the diff, and when you exit you can make the choice again.

Good idea!

ctrl-c in prompt

Should be fixed with b971531. It's a bit less efficient but should restore the user's terminal under more circumstances.

The terminal isn't messed up after ctrl-c anymore, so that's great! Still, the weird chezmoi: output stays.

Ack, will investigate.

chezmoi2 apply is a lot slower than chezmoi1

I added 2c06aba but this doesn't solve the problem, it's just a step along the path.

The apply times I showed above were for when there were no changes to be applied. Chezmoi2 diff isn't actually slower than chezmoi1, so could you maybe just test if there is a difference and then apply? Or are there other things to do as well?

I did a bit of profiling on this, and I'm pretty sure the difference is that chezmoi2 checksums every file to see if it has changed since chezmoi last wrote it, and about 50% of the CPU time is spent computing checksums. This does slow chezmoi2 down (chezmoi1 doesn't do this and so doesn't pay this price), but chezmoi is still overwhelmingly I/O bound and I think the extra value of the functionality is worth the increase in runtime (which remains in the order of a few hundred milliseconds).

where is the pager?

I see the option --no-pager in the chezmoi diff --help output. How do I get chemzoi to show me a pager with the diff output?

Good catch! This should be fixed with 0a37bea.

File permissions not correct

This is great feedback and challenges the assumptions that chezmoi2 is making. tl;dr chemzoi2 only checks that permissions are correct with respect to the user's umask.

I don't really get how comparing to the umask works, but wouldn't it be easier to just check if permissions1==permissions2?

I wish! The tl;dr is that umask means that "what what you read is not what you wrote". For example, If I write a file with permission 777 on a system with umask 002 and then read back its permissions then I get 0775, so I can't do a simple check that the permissions are equal: I have to take the umask into account.

[JustinGrote]

@twpayne The state version check fails with snapshotted images. My PR only fixes it if the specified commit is tagged because goreleaser still does snapshots even if you don't specify --snapshot if the commit isn't tagged.

Only other option I can think is to maybe hardcode 0.0.1 as the version if not specified (which will be higher than 0.0.0 in semantic versioning)
chezmoi: source state requires version 0.0.0 or later, chezmoi is version 0.0.0-SNAPSHOT-3bc8688

[twpayne]

The right way to fix this might be to ignore the required version if chezmoi's version is zero (indicating a dev build).

[twpayne]

file has changed, do you want to overwrite?

Hopefully fixed with 7ecad8c. This makes the prompted choices more explicit, and still allows the user to use abbreviations (e.g. y for yes).

Yes that makes it a lot more clear. An option for diffing the two files would be a great addition. This would need to bring up a pager with the diff, and when you exit you can make the choice again.

#1015 adds the diff, pager not added yet.

[JustinGrote]

@twpayne probably not a big deal but on windows the LookupGroupId returns a SID rather than an individual number and I think it is only being interpreted within a unix context

This is seen with chezmoi2 status --debug
2021-01-26T19:19:06-08:00 DBG user.LookupGroupId error="lookupGroupId: should be group account type, not 1" gid=S-1-12-1-974465898-1145538818-2076912041-298801854

[JustinGrote]

@twpayne on the windows side, chezmoi2 -f to follow a symbolic link seems to be working for both symlinks and ntfs junctions, however if I deep-link a file, the intermediate items don't respect the -f so they get created as a symbolic link first and fail.

I set up three folders: Temp, sltest (symbolic link to temp) and jtest (ntfs junction to test) and put a text.txt file in there.

❯ get-item jtest,sltest,temp     

    Directory: C:\Users\JGrote

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
l----           1/26/2021  7:54 PM                JTest -> C:\Users\JGrote\Temp
la---           1/26/2021  7:54 PM              0 sltest -> Temp
d-r--           1/26/2021  7:55 PM                Temp

Then this fails, only creating a symbolic link to sltest, when in fact the -f should have said "first follow sltest and create it as a folder, then follow and fetch the inner text.txt"

> chezmoi add --debug --verbose -r -f $HOME\SLTest\text.txt
2021-01-26T20:05:30-08:00 DBG Stat name="C:\\Users\\JGrote\\.config/chezmoi/chezmoistate.boltdb"
2021-01-26T20:05:30-08:00 DBG Mkdir error="mkdir C:/Users/JGrote/.local/share/chezmoi: Cannot create a file when that file already exists." name=C:/Users/JGrote/.local/share/chezmoi perm=511
2021-01-26T20:05:30-08:00 DBG Stat name=C:/Users/JGrote/.local/share/chezmoi
2021-01-26T20:05:30-08:00 DBG Lstat name=C:/Users/JGrote/.local/share/chezmoi
2021-01-26T20:05:30-08:00 DBG Lstat name=C:/Users/JGrote/SLTest
2021-01-26T20:05:30-08:00 DBG Readlink linkname=./Temp name=C:/Users/JGrote/SLTest
2021-01-26T20:05:30-08:00 DBG ReadFile data="Lorem Ipsum" filename=C:/Users/JGrote/SLTest/text.txt
2021-01-26T20:05:30-08:00 DBG Lstat error="CreateFile C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest: The system cannot find the file specified." name=C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest
2021-01-26T20:05:30-08:00 DBG Stat error="CreateFile C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest: The system cannot find the file specified." name=C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest
diff --git a/symlink_SLTest b/symlink_SLTest
new file mode 100644
index 0000000000000000000000000000000000000000..1da2d0ed26f64f396d25e32dbbb69d3a8a12a0e7
--- /dev/null
+++ b/symlink_SLTest
@@ -0,0 +1 @@
+./Temp
2021-01-26T20:05:30-08:00 DBG WriteFile data="./Temp\n" name=C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest perm=438
2021-01-26T20:05:30-08:00 DBG Set bucket=entryState key=C:/Users/JGrote/SLTest value="{\n  \"type\": \"symlink\",\n  \"contentsSHA256\": \"b63c850c12ddb1fa19932fb913e514be9e7d7b4613959e9647e84a53117afd86\"\n}\n"
2021-01-26T20:05:30-08:00 DBG Lstat error="CreateFile C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest/text.txt: The system cannot find the path specified." name=C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest/text.txt
2021-01-26T20:05:30-08:00 DBG Stat error="CreateFile C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest/text.txt: The system cannot find the path specified." name=C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest/text.txt
diff --git a/symlink_SLTest/text.txt b/symlink_SLTest/text.txt
new file mode 100644
index 0000000000000000000000000000000000000000..fc1c3cfb81b562fe79d85193c33800977199780f
--- /dev/null
+++ b/symlink_SLTest/text.txt
@@ -0,0 +1 @@
+Lorem Ipsum
\ No newline at end of file
2021-01-26T20:05:30-08:00 DBG WriteFile error="open C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest/text.txt: The system cannot find the path specified." data="Lorem Ipsum" name=C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest/text.txt perm=438
chezmoi: open C:/Users/JGrote/.local/share/chezmoi/symlink_SLTest/text.txt: The system cannot find the path specified.

❯ get-item C:\Users\JGrote\.local\share\chezmoi\symlink_SLTest

    Directory: C:\Users\JGrote\.local\share\chezmoi

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           1/26/2021  8:05 PM              7 symlink_SLTest

However if I do the folder first without recursion, then it's OK.

chezmoi add -f $HOME\SLTest
chezmoi add -f $HOME\SLTest\text.txt

❯ get-childitem C:\Users\JGrote\.local\share\chezmoi\SLtest

    Directory: C:\Users\JGrote\.local\share\chezmoi\SLTest

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           1/26/2021  8:08 PM             11 text.txt

So clearly the intermediary is just missing a flag to tell it to follow the symlink too and create a directory in source rather than a symlink to that directory. Obviously it should error if a symlink already exists, warning the user to delete the symlink in source if they want chezmoi to specificially manage "sub" files.

[JustinGrote]

.chezmoiignore: ! Filters not taking precedence per the reference

https://www.chezmoi.io/docs/reference/#chezmoiignore

Patterns can be excluded by prefixing them with a ! character. All excludes take priority over all includes.

Does not seem to work. For example:

Capture.mp4

[twpayne]

Thanks for the in-depth testing @JustinGrote!

on windows the LookupGroupId returns a SID rather than an individual number and I think it is only being interpreted within a unix context

Ah, thanks for the insight here. Basically, as far as I can tell, Go's os/user package doesn't really support groups on Windows, and it's unlikely that people are using the .chezmoi.group template variable in their dotfiles anyway. chemzoi currently ignores the error. It probably makes more sense to avoid even trying to populate .chezmoi.user on Windows.

if I deep-link a file, the intermediate items don't respect the -f so they get created as a symbolic link first and fail.

Do you mean --follow instead of -f? Note that -f is short for --force. Note also that --follow is working as intended here. From the docs:

--follow
If the last part of a target is a symlink, add the target of the symlink instead of the symlink itself.

Under the hood, --follow causes chezmoi to use os.Stat instead of os.Lstat to determine what's being added. Adding directory structures with symbolic links/NTFS junctions becomes very complex very quickly (chezmoi add is already by far the most complex part of chezmoi) so I would prefer leaving this to the user to deal with for now (but that's not to say that chezmoi can't to better in the future, potentially up-for-grabs).

.chezmoiignore: ! Filters not taking precedence per the reference

In the example here, .chezmoiignore contains:

!Documents/Powershell/profile.ps1
Documents

Documents is a parent of Documents/Powershell/profile.ps1. chezmoi currently does not recurse into ignored directories and so the more-specific pattern of !Documents/Powershell/profile.ps1 is never tested. You're right that this behavior is inconsistent with the description of in the reference manual. Both making chezmoi behave consistently with the reference manual and/or correcting the reference manual with a more accurate description are both up-for-grabs.

[twpayne]

where is the pager?

I see the option --no-pager in the chezmoi diff --help output. How do I get chemzoi to show me a pager with the diff output?

Done in a2f567d. Note also that --no-pager is now a global flag (b0ad705).

on windows the LookupGroupId returns a SID rather than an individual number and I think it is only being interpreted within a unix context

Ah, thanks for the insight here. Basically, as far as I can tell, Go's os/user package doesn't really support groups on Windows, and it's unlikely that people are using the .chezmoi.group template variable in their dotfiles anyway. chemzoi currently ignores the error. It probably makes more sense to avoid even trying to populate .chezmoi.user on Windows.

Group lookup skipped on Windows with 9ee00ef.

[MunifTanjim]

I just found this in #831:

All run_first_ scripts are run before files, directories, and symlinks are updated. All run_last_ scripts are run after files etc. are updated.

Not a technical issue, but a linguistic one. I think the initially planned pre_-post_ or before_-after_ would be a better choice of words here.

For example, if I have two scripts run_first_something.sh and run_first_something_else.sh, both of them can't really be the "first". Same goes for "last".

Since v2 is still in early beta, this can be replaced with more appropriate words.

[twpayne]

Not a technical issue, but a linguistic one. I think the initially planned pre_-post_ or before_-after_ would be a better choice of words here.

Thank you @MunifTanjim for this feedback!

The reason for first_ and last_ replacing pre_ and post_ was that I wanted chemzoi's source file names to follow English adjectival order while maintaining the source state entry type in the first position to assist visual scanning of the source directory. Pre- and post- are modifiers, so scripts would have to have been called pre_run_ and post_run_, which is why I switched to run_first_ and run_last_.

That all said, your suggestion for run_before_ and run_after_ are excellent. It's a bit of a shame that "before" sorts lexicographically after "after", i.e. it would be nice if we could find a pair of adjectives where the earlier occurs before the latter (as is the case with "first" and "last").

All this to say, great input and thank you for this feedback - commit coming up.

[twpayne]

chezmoi2 apply isn't non-interactive anymore

As mentioned in #992, I automatically apply files from vim. With chezmoi1 this didn't require any interaction, but now it does. You have to specify --keep-going and --no-tty to make it non-interactive in vim (vim apparently doesn't provide a tty to shell commands). I would suggest adding an option like --overwrite=[false/true] to make it non-interactive again.

Come to think of it, most of these issues are with the overwrite functionality added in chezmoi2. I think this change can be confusing for old and new users and could potentially break things. I didn't check if it's possible now, but I would definitely recommend adding an option to disable this feature.

This is by design. The --force option will make chezmoi apply non-interactive and apply all changes without asking (equivalent to the --overwrite option you propose). chezmoi apply is deliberately interactive now when chezmoi detects that a dotfile has been modified by a third party: this is to make chezmoi "safe" by default (#423).

[twpayne]

File permissions not correct

After adding something to the file /usr/share/chezmoi/dot_vimrc, and applying the changes with chezmoi2 apply, the permissions changed from 644 to 666. chezmoi1 detects that the permissions have changed, so a chezmoi apply fixes it. Chezmoi2 diff, however, doesn't seem to detect this specific change (from 666 to 644). Adding a +x to the destination file is detected by chezmoi2.

Thanks for spotting this @fwsmit! This should be fixed with 22bef17.

[fwsmit]

File permissions not correct

After adding something to the file /usr/share/chezmoi/dot_vimrc, and applying the changes with chezmoi2 apply, the permissions changed from 644 to 666. chezmoi1 detects that the permissions have changed, so a chezmoi apply fixes it. Chezmoi2 diff, however, doesn't seem to detect this specific change (from 666 to 644). Adding a +x to the destination file is detected by chezmoi2.

Thanks for spotting this @fwsmit! This should be fixed with 22bef17.

Can confirm it works now!

chezmoi2 apply isn't non-interactive anymore

This is by design. The --force option will make chezmoi apply non-interactive and apply all changes without asking (equivalent to the --overwrite option you propose). chezmoi apply is deliberately interactive now when chezmoi detects that a dotfile has been modified by a third party: this is to make chezmoi "safe" by default (#423).

Okay, that's a good solution.

where is the pager?

I see the option --no-pager in the chezmoi diff --help output. How do I get chemzoi to show me a pager with the diff output?

Done in a2f567d. Note also that --no-pager is now a global flag (b0ad705).

I don't see any pager in chezmoi diff output yet, even though the output is more than a screen long.

[twpayne]

I don't see any pager in chezmoi diff output yet, even though the output is more than a screen long.

Do you have diff.pager set in your config file? e.g.

[diff]
  pager = "less"

[fwsmit]

I don't see any pager in chezmoi diff output yet, even though the output is more than a screen long.

Do you have diff.pager set in your config file? e.g.

[diff]
  pager = "less"

No, but I do have $PAGER set to less in my environment. I think you should at least check if that variable is set, and maybe just default to less if it isn't set.
For users that don't want a page there could be an option in the settings to always disable the pager.

[twpayne]

Thanks @fwsmit, done in 5b228cc.

By default chemzoi2 will use:

1. diff.pager if set.
2. Otherwise, $PAGER.
3. Otherwise, less.

Disable the pager by setting diff.pager to the empty string or by using the --no-pager option.

[caius]

Currently in the process of moving to chezmoi from homegrown script over in caius/zshrc#6. Testing what I currently have against chezmoi2 works fine, once I read the Changelog and realised homedir had become homeDir. (Completely fine, totally my failure to read properly. 😂 )

[twpayne]

Firstly thank you to @zb140 @fwsmit @JustinGrote @MunifTanjim @caius for all your work in testing, feedback, and contributions. Thanks to your efforts, it seems that chezmoi2 is now reasonably solid.

I think that all the feedback from this issue has now been addressed, please add a comment here if there is something that has been missed.

The current plan is to release chezmoi2 a few days after Go 1.16 is released. I'll open a new issue for this.

Thank you again for all your testing and feedback :)