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
chezmoi status currently uses the first column for "difference between target state and previous apply", and the second for "difference between target state and next apply" (or, equivalently, difference between target state and source). So, for example, we get things like:
A - new file in source state; chezmoi apply will create it
DA - a file chezmoi previously knew about has been deleted; chezmoi apply will recreate it
M - a file previously created by chezmoi has changed in source; chezmoi apply will update it in the target, and chezmoi diff will show you what the update would consist of.
This, however, results in an infelicity when you have made local edits to a file and not yet propagated them back to chezmoi. Let's consider three files:
.zshenv is edited in the source;
.zshrc is edited in the target;
and .zprofile is edited in both, but in different ways (as might happen in practice from, say, a git pull picking up changes to it from another machine, when you've made but not yet added local changes to it)
$ chezmoi status
$ $EDITOR .zshrc # changed in target but not souce
$ chezmoi edit .zshenv # changed in source but not target
$ chezmoi edit .zprofile &&$EDITOR .zprofile # changed in both but differently
$ chezmoi status
M .zshenv
MM .zprofile
MM .zshrc
Note that chezmoi status cannot distinguish here between "we edited it and need to save those edits with chezmoi add", and "we have an edit/edit conflict that needs to be manually resolved". We need to look at the diff to tell them apart, and depending on the nature of the edits even that isn't always obvious.
Proposed Solution
Since chezmoi keeps an internal record of what it last wrote to the target (for, e.g., the "file has changed since chezmoi last wrote it" warning on chezmoi apply), it should be possible for it to distinguish between these two cases. Intuitively, it seems like displaying MM for the edited/edited case and M for the case where it's only edited in the target would work well, and would be symmetric with the existing M output for the unmodified/edited case.
Unfortunately, this violates the current constraint that the second column is "the difference between target and source". I think my preferred solution would be to redefine that as "how the source has changed since your last chezmoi apply", which will give the same output in common cases, and in uncommon ones will make it clearer whether changes are coming from edits to the target, updates to the source, or both.
Alternatives Considered
Special-casing M to mean "target modified, source unchanged since last apply" might be simpler, but is less internally consistent. The same applies to adding a new character (e.g. X or C) for "edit/edit conflict" and reporting that line as CM or something.
Adding a third column (so that our columns reflect "target vs. last apply", "target vs. next apply", and "last apply vs. next apply") doesn't require changing the meaning of the existing second column, but, I think, makes the output more confusing overall and is not necessary for this.
Changing my workflow to always use chezmoi edit --apply works only if I am very diligent about it, which realistically I probably won't be. I have considered wrapping my editor in a script that automatically detects when I'm editing cm-managed files (or files that probably should be managed by cm), and may yet do that, but I think even if I do this the improved chezmoi status output would be welcome.
The text was updated successfully, but these errors were encountered:
Problem Description
chezmoi status
currently uses the first column for "difference between target state and previous apply", and the second for "difference between target state and next apply" (or, equivalently, difference between target state and source). So, for example, we get things like:A
- new file in source state;chezmoi apply
will create itDA
- a file chezmoi previously knew about has been deleted;chezmoi apply
will recreate itM
- a file previously created by chezmoi has changed in source;chezmoi apply
will update it in the target, andchezmoi diff
will show you what the update would consist of.This, however, results in an infelicity when you have made local edits to a file and not yet propagated them back to chezmoi. Let's consider three files:
.zshenv
is edited in the source;.zshrc
is edited in the target;.zprofile
is edited in both, but in different ways (as might happen in practice from, say, a git pull picking up changes to it from another machine, when you've made but not yet added local changes to it)Note that
chezmoi status
cannot distinguish here between "we edited it and need to save those edits withchezmoi add
", and "we have an edit/edit conflict that needs to be manually resolved". We need to look at the diff to tell them apart, and depending on the nature of the edits even that isn't always obvious.Proposed Solution
Since chezmoi keeps an internal record of what it last wrote to the target (for, e.g., the "file has changed since chezmoi last wrote it" warning on
chezmoi apply
), it should be possible for it to distinguish between these two cases. Intuitively, it seems like displayingMM
for the edited/edited case andM
for the case where it's only edited in the target would work well, and would be symmetric with the existingM
output for the unmodified/edited case.Unfortunately, this violates the current constraint that the second column is "the difference between target and source". I think my preferred solution would be to redefine that as "how the source has changed since your last
chezmoi apply
", which will give the same output in common cases, and in uncommon ones will make it clearer whether changes are coming from edits to the target, updates to the source, or both.Alternatives Considered
Special-casing
M
to mean "target modified, source unchanged since last apply" might be simpler, but is less internally consistent. The same applies to adding a new character (e.g. X or C) for "edit/edit conflict" and reporting that line asCM
or something.Adding a third column (so that our columns reflect "target vs. last apply", "target vs. next apply", and "last apply vs. next apply") doesn't require changing the meaning of the existing second column, but, I think, makes the output more confusing overall and is not necessary for this.
Changing my workflow to always use
chezmoi edit --apply
works only if I am very diligent about it, which realistically I probably won't be. I have considered wrapping my editor in a script that automatically detects when I'm editing cm-managed files (or files that probably should be managed by cm), and may yet do that, but I think even if I do this the improvedchezmoi status
output would be welcome.The text was updated successfully, but these errors were encountered: