From: Jeff King Date: Tue, 12 Jul 2011 18:25:17 GMT Subject: Re: [RFC] control, what refs are honored by core.logAllRefUpdates Message-ID: <20110712182517.GA17787@sigill.intra.peff.net> In-Reply-To: On Tue, Jul 12, 2011 at 08:15:21PM +0200, Bert Wesarg wrote: > >> Setting core.autoLogRef to the empty value, will reset the list. > > > > It is unclear what it is reset to.  Do you mean it clears, e.g. > > > >    [core] > >        autoLogRef = heads > >        autoLogRef = remotes > >        autoLogRef = notes > >        autoLogRef = > >        autoLogRef = heads > > > > would first create a list of three elements, clears it and then the final > > result has only refs/heads/ in the list? > > > Exactly. I think the --notes option does have a similar semantics. (I > added Jeff to the Cc). There is --no-notes, which resets the notes > list and than subsequent --notes= options populate the list again. Yeah, --notes versus --no-notes is as you say. This topic came up recently when discussing config for the user-defined archive filters, too. This is a fairly natural solution, as it lets you say "append to what's there" versus "replace what's there", which is what you really want[1]. I think I'd rather see something more syntactically explicit for resetting, though, like: [core] autoLogRef = heads autoLogRef = remotes autoLogRef = notes !autoLogRef autoLogref = heads (for that matter, I have often wished that "!autoLogRef" was boolean false, just as "autoLogRef" is boolean true). But it may not be worth changing the config syntax for. -Peff [1] If we were starting from scratch, you could make that distinction with a new operator, like: [core] autoLogRef = heads autoLogRef += remotes autoLogRef += notes autoLogRef = heads which would be equivalent to what you wrote above. But because it switches the semantics of "=" to "replace" instead of "append" for multi-value keys, it would break all current config that uses multiple "fetch" lines (for example).