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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html