Closed nivaca closed 4 months ago
Depending on what you’re using, that could be quite dangerous. My .config/git/config
is templated, so a re-add option would destroy the template options with fixed resolution.
If you often modify files outside of chezmoi (like I do), it is worthwhile using chezmoi merge TARGET
or chezmoi merge-all
.
I agree that this would be a nice feature. However, there are a couple of difficulties in implementing it:
re-add
only works on simple files.re-add
option would directly violate this as it modifies the source state directly while chezmoi apply
is running.So, I'll add this as a potential v3
feature. There is no ETA for this.
Thanks to both of you. So re-add
should only be used with non-template files, you mean?
Probably? I don’t think that I’ve ever used chezmoi re-add
, because I find the workflow of chezmoi merge
or chezmoi merge-all
so much better. If I am performing an apply
and see a file that I did not expect to see, I check the diff and if I don’t like it, I q
uit the apply (or sometimes just hit C-c
).
So
re-add
should only be used with non-template files, you mean?
re-add
can only be used with non-template files, otherwise the template would be overwritten. It's not possible to "reverse execute" a template.
So
re-add
should only be used with non-template files, you mean?
re-add
can only be used with non-template files, otherwise the template would be overwritten. It's not possible to "reverse execute" a template.
Having never used re-add
, does chezmoi warn if a template is about to be overwritten? If not, perhaps it should.
(What follows is pure speculation about what might be better for v3, since it would involve incompatible changes.)
It feels like re-add
should probably be removed as its behaviour is potentially dangerous—I think that it may be seen as "roughly equivalent" to chezmoi add
, and I don't think it is. A couple of flags to add
might be better for various cases than just re-add
:
chezmoi add
with no flags should error out if the target already exists (this may happen already). Depending on what is tried with chezmoi add
, it could recommend the correct commands to use (e.g., trying to add with different permissions might suggest chezmoi chattr …
).chezmoi add --replace
would behave like the current chezmoi re-add
. Using --replace
(I would recommend against a shorthand version of the flag) would make it clear this is what you’re doing.chezmoi add --merge
would essentially switch to executing chezmoi merge …
. chezmoi add
could behave differently than erroring out if we wanted to build in some prompting, producing the output of chezmoi diff …
and prompt to merge (edit)
, skip
, replace
or whatever for each file.
The behavior of re-add
is documented.
It's useful enough in its current form (at least, it's part of several people's workflow) that it's worth keeping as-is.
I now understand the perils of using re-add
automatically. However---and this is a more basic question---I have not grasped the use of merge
and merge-all
. If I change a (local) file, and I run chezmoi merge-all
(or chezmoi merge <file>
), I get the three-pan diff (using vimdiff or whatever). If I make any changes there, I have noticed that chezmoi doesn't push them to the git repo. So I'm at a loss here.
Do you have any of git.autoAdd
, git.autoCommit
, or git.autoPush
set?
Do you have any of
git.autoAdd
,git.autoCommit
, orgit.autoPush
set?
I have the two latter set to true, but nothing on the first one.
I set git.autoAdd
to true and everything works as expected now. Thanks.
Is your feature request related to a problem? Please describe.
When running
chezmoi update
and I get a notification saying that a file has been changed, and it happens that I approve of the change, I have toskip
the update and then runchezmoi re-add
to commit the changes.Describe the solution you'd like
A
re-add
option in the available options offered bychezmoi update
would be great in order to streamline the workflow.Describe alternatives you've considered
I
skip
the update and thenre-add
the file. Two steps.