patchDocumentation: clearly specify what refs are honored by core.logAllRefUpdates

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.

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>

---

The initial justification in 4057deb (Junio C Hamano, 2006-10-08), leaves
the impression, that a blacklist would have made more sense, than the
current whitelist. Maybe we can change this?
---
 Documentation/config.txt         |    4 +++-
 Documentation/git-update-ref.txt |    5 +++--
 2 files changed, 6 insertions(+), 3 deletions(-)

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

Thanks.

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:

	[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

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

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.

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

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

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

Minor typo; see below.

On 07/11/2011 11:14 AM, Bert Wesarg wrote:

s/reafs/refs/

On Tue, Jul 12, 2011 at 06:39, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Thanks.

Junio, you applied this already to pu, do you need a patch?

Bert