On Mon, Jul 11, 2011 at 19:29, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> writes:
>
>> The documentation for logging updates in git-update-ref, doesn't make it
>> clear that only a specific subset of refs are honored by this variable.
>
> Thanks.
>
>> The initial justification in 4057deb (Junio C Hamano, 2006-10-08), leaves
>> the impression, that a blacklist would have made more sense,...
>
> I didn't mean it that way, and I still don't think blacklisting is
> feasible nor necessarily desirable. Different porcelains can use
> namespaces under refs/ for their own purposes, and it would be more
> prudent not to create reflog files that can grow long and not useful
> given that we cannot predict/guess what they are used for and how, so
> I would prefer white-listing the ones that are known to be useful.
>
> It might make sense to allow customizing the white-list via the
> configuration mechanism, though. When your favorite third-party git
> "frotz" add-on uses refs/frotz/ hierarchy for its own purpose, and if
> viewing "git log -g frotz/master@{now}" is useful, you may want to be able
> to say "In addition to the standard ones, please log refs/frotz/*
> automatically". Of the top of my head, something like:
This sounds like a good idea, and with the -c option you could use it like this:
git -c core.autoLogRef=frotz update-ref -m foo refs/frotz/master <sha1>
without having the trouble to set this config inside git-frotz
Actually, I tried also to add something like --force or --always-log
as an option to update-ref, so that the log file is created
automatically. But that doesn't looked that trivial.
>
> [core]
> autoRefLog = refs/heads/*
> autoRefLog = refs/remotes/*
> autoRefLog = refs/notes/*
>
> or less expressive but even simpler and probably sufficient:
>
> [core]
> autoRefLog = heads remotes notes
>
> can be the spelled-out form of traditional "core.logAllRefUpdates", and
> you may be able to tweak it like:
>
>
> [core]
> autoRefLog = heads remotes notes frotz
>
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. Thus, this config should only adds to
the list, but never resets.
Bert
--
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