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