Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook

If it was in a temporary directory, even if I manaually resolved the file
and merge, I was expecting that file marked as resolve to stay in that
temporary directory until I was done with all my files. Maybe I'm confusing
mergemaster -Ui behavior with something else, but it seems like only
merging after the user has reviewed all manual changes in a final
verification sweep is common sense or at least explicitly display the tree
directory that would be written to and say this is final change. I didn't
know that each file etcupdate went over was going to be the final review. I
think my system broke by the time I got to the rest of the postponed items
due to this.

On Wed, Dec 8, 2021, 9:05 AM John Baldwin <jhb@freebsd.org> wrote:

> On 12/3/21 4:58 AM, Miroslav Lachman wrote:
> > So beside the update of documentation I really would like to see some
> > changes to etcupdate workflow where files are modified in temporary
> > location and moved to destination only if they do not contain any syntax
> > breaking changes like <<<<, ====, >>>>.
>
> This is what etcupdate does, so I'm a bit confused why you are getting
> merge markers in /etc.  When an automated 3-way merge doesn't work due
> to conflicts, the file with the conflicts is saved in
> /var/db/etcupdate/conflicts/<path>.  It is only copied to /etc when you
> mark it as fully resolved when running 'etcupdate resolve'.  Perhaps
> you had multiple conflicts in a modified file and when editing the file
> you only fixed the first one and then marked it as resolved at the
> prompt?  Even in that case etcupdate explicitly prompts you a second time
> after you say "r" with "File <foo> still has conflicts, are you sure?",
> so it will only install a file to /etc with those changes if you have
> explicitly confirmed you want it.
>
> --
> John Baldwin
>