Re: [RFC] control, what refs are honored by core.logAllRefUpdates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]