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

From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Jul 12, 2011, 18:15 UTC
Message-ID: <CAKPyHN0+BaPtrRMVrWCZQ2mbJQz_vxsOOsG4Z=Ksqc1RJvF1Ew@mail.gmail.com>
In-Reply-To: <7vaacj8jq7.fsf@alter.siamese.dyndns.org>

On Tue, Jul 12, 2011 at 19:57, Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> What: Control the refs which are honored by core.logAllRefUpdates.
>>
>> How:
>>
>> Introduce a new config variable named core.autoRefLog. This variable
>> is a multi var. The default value is:
>>
>>     [core]
>>         autoLogRef = heads
>>         autoLogRef = remotes
>>         autoLogRef = notes
>>
>> This list must be initialize at runtime. Because older repositories
>> won't have them in existing config files.
>
> It sounds as if you mean to update .git/config when you find a repository
> that is missing these, which is not what we want.  I would rephrase it
> like this:

No, that was not my intention. I meant that the list is set to the current hard-coded list. And than subsequent code.autoLogRef values alter this list. So no 'conversion' will be done.

Show 5 quoted lines

>
>  - The new variable core.autoLogRef is a multi-valued configuration.
>
>  - If core.autoLogRef is defined (to any value), core.logAllRefupdates is
>   ignored;

I haven't though of this logic. But it sounds good. Specifying any core.autoLogRef should be honored, regardless whether core.logAllRefupdates is set.

Show 32 quoted lines

>
>  - Otherwise, the core.logAllRefUpdates variable that is set to true is
>   equivalent to having a "reasonable default" set in core.autoLogRef (and
>   the current "reasonable default" happens to be heads, remotes and
>   notes), and the core.logAllRefUpdates variable set to false (or
>   missing) is equivalent to having an empty string in core.autoLogRef;
>
>> The value given needs to be a valid ref, without leading or trailing
>> slashes, and wildcards. The names will be prefixed with 'refs/' and
>> suffixed with '/'. The list is checked against the ref to update, if
>> any of the values is a prefix of the given ref, than the update will
>> be logged, regardless whether the log file exists.
>
> Ok, except for:
>
>  - An empty string in core.autoLogRef does not contribute to the matching
>   logic above.
>
>> 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.

Bert