Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

>
>  * when we observe a config file, we could walk each option present in
>    it.  For each option:
>
>     a) if that option is not present in the database, copy it into the
>        database.
>
>     b) if that option is present in the database, and it matches the
>        option in the config file, ignore
>
>     c) if that option is present in the database but does not match the
>        config file, use the version in the config file but warn the user
>        that they have a conflict they should probably resolve soon.

I guess this whole discussion is about the CLI, so in principle that's
OK, but for existing library code there's no real way to use the config
file value for config values that are stored in the database: we just
don't pass that information in to the API. What's (relatively) easy is
to have the config file reader used by the CLI check for conflicts with
the database config and report those. We could also give people a flag
(or something) so that the database version of the config is
overwritten.

Really, writing the database config from the text config file seems
relatively sane to me. It's editing that file via computer that gives me
the heebie-jeebies.

> So i think it would be a shame to have an additional layer of confusion
> added by having two different deprecated configuration files.  So i lean
> against adopting this change. I'd much rather see work on phasing out
> the configfile.

OK, noted. I guess I would imagine any conflict resolution to be against
the in-memory struct read from disk, so somewhat orthogonal to where it
is read from.
_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch