On Mon, Jul 11, 2011 at 23:24, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> 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.
--
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