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