On Thu, Apr 25 2019, Jonathan Nieder wrote: > Ævar Arnfjörð Bjarmason wrote: > >> Because we don't have some general config facility for this it keeps >> coming up, and various existing/proposed options have their own little >> custom hacks for doing it, e.g. this for Barret Rhoden's proposed "blame >> skip commits" feature >> https://public-inbox.org/git/878swhfzxb.fsf@xxxxxxxxxxxxxxxxxxx/ >> (b.t.w. I *meant* /dev/null in that E-Mail, but due to PEBCAK wrote >> /dev/zero). > > I'm confused. Isn't that bog-standard Git usage, not a custom hack? > That is, I thought the intended behavior is always > > 1. For single-valued options, last value wins. > 2. For multi-valued options, empty clears the list. > 3. When there is a special behavior triggered by not supplying the > option at all, offer an explicit value like "default" that triggers > the same behavior, too. > > and that any instance of a command that isn't following that is a bug. > > Which of course leaves room for improvement in documentation and how > we organize the implementation (as Peff discussed in [1]), but isn't > it nice to already have something in place that doesn't require > inventing a new syntax? We can quibble over the wording, but I'd say that's a "hack". Yeah for *some* options setting it to an empty value clears whether it's a single-value or multi-value. But it's entirely dependent on the specific callback implemented for that option, sometimes there's no way to "reset" something, and in the best case you'd need to exhaustively enumerate everything (e.g. for the sendemail.* stuff) and hope nobody adds a new option tomorrow, you can't say "clear this wildard" or "no config from system-wide". So I think it makes sense to think about how we could promote this to the config syntax itself so that what somewhat-mostly-but-not-quite works now by convention would be guaranteed to work, and things that you can't do at all today (e.g. ignore system config, or selectively ignore something) would be supported.
