Re: How to undo previously set configuration? (again)
- From
- Barret Rhoden <brho@google.com>
- Date
- Apr 25, 2019, 14:43 UTC
- Message-ID
- <74ea0269-3e4f-1f6a-c060-c5ac969b91e8@google.com>
- In-Reply-To
- <20190425143614.GA91608@google.com>
Hi -
On 4/25/19 10:36 AM, Jonathan Nieder wrote:
Show 21 quoted lines
> Hi, > > Æ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@evledraar.gmail.com/ >> (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.
Not sure if it's meant to be the standard, but I just went with the style used by credential.helper. This was suggested to me by Johannes in [1]:
On 2019-01-18 at 10:47 Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 5 quoted lines
> A better idea IMHO would be to use an OPT_STRING_LIST() for > `--ignore-revs-file`, too, and to allow for multiple > `blame.ignoreRevsFile` config entries (with our usual trick of handling an > empty setting by resetting the list of paths that were accumulated so > far, see e.g. how `credential.helper` is handled).
[1] https://public-inbox.org/git/nycvar.QRO.7.76.6.1901181038540.41@tvgsbejvaqbjf.bet/
Barret