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

On Mon, Jul 11, 2011 at 23:24, Junio C Hamano <gitster@pobox.com> wrote:

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.

Bert Wesarg <bert.wesarg@googlemail.com> writes:

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;

Ok, except for:

 - An empty string in core.autoLogRef does not contribute to the matching
   logic above.

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?

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

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.

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

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

On Tue, Jul 12, 2011 at 08:15:21PM +0200, Bert Wesarg wrote:

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

Jeff King wrote:

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

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

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

Bert

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

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