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

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

[Bert Wesarg]

On Mon, Jul 11, 2011 at 23:24, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> The question is: should the user be able to disable logging of the
>> hard-coded values. With your examples that would be possible. But I
>> think we should not allow that.
>
> You have to justify that position. I do not see any reason to forbid
> myself from declining reflog for refs/remotes/ while still logging the
> updates to my refs/heads/.

I don't, because I don't care. But I care for a simple way to always
log ref updates with update-ref. Thus, I take you justification for
being able to do so and provide here a proposal for this:

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.

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.

Setting core.autoLogRef to the empty value, will reset the list.

Usecase:

To be able to always log ref updates from update-ref in one call. For example:

    git -c core.logAllRefUpdates=true -c core.autoLogRef=frotz
update-ref -mreason refs/frotz/master <new-value>

Please note, that there is also the "HEAD" ref, which is honored by
core.logAllRefUpdates. I don't know how this should be handled by
core.autoLogRef. I have no problem that this will be hardcoded.

Kind regards,
Bert

PS: I asked for the typo in my applied patch, but you are only on Cc,
which should have been To. Please feel directly asked. Thanks.

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

[Junio C Hamano]

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:

 - The new variable core.autoLogRef is a multi-valued configuration.

 - If core.autoLogRef is defined (to any value), core.logAllRefupdates is
   ignored;

 - 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?

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

[Bert Wesarg]

On Tue, Jul 12, 2011 at 19:57, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

>
>  - 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.

>
>  - 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

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

[Jeff King]

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).

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

[Jonathan Nieder]

Jeff King wrote:

> 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.

Sounds worthwhile to me.  I've (probably irrationally) wished before
for an abbreviation for "bare = false", too.

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

[Bert Wesarg]

On Tue, Jul 12, 2011 at 20:25, Jeff King <peff@peff.net> wrote:
 [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).

Adding ! as a negator would also break config files read by old git versions.

Bert

>

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

[Jeff King]

On Wed, Jul 13, 2011 at 10:52:58AM +0200, Bert Wesarg wrote:

> On Tue, Jul 12, 2011 at 20:25, Jeff King <peff@peff.net> wrote:
>  [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).
> 
> Adding ! as a negator would also break config files read by old git versions.

True. I consider that less bad than "existing config files are broken",
but it is still worth thinking about. It really only affects people who
move back and forth between git versions using the same set of config
files.

In general, our config stays pretty compatible between versions, but
there are exceptions. E.g., older versions of git will complain about:

  [pager]
    log = whatever

because "pager.*" previously had to be a bool. I run into this when
testing old git versions.

I have no idea how common that sort of thing is with regular users,
though.

-Peff