[PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates

[PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates

[Bert Wesarg]

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

diff --git a/Documentation/config.txt b/Documentation/config.txt
index c631d1c..dd44122 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -344,7 +344,9 @@ core.logAllRefUpdates::
 	SHA1, the date/time and the reason of the update, but
 	only when the file exists.  If this configuration
 	variable is set to true, missing "$GIT_DIR/logs/<ref>"
-	file is automatically created for branch heads.
+	file is automatically created for branch heads (i.e. under
+	refs/heads/), remote reafs (i.e. under refs/remotes/),
+	note refs (i.e. under refs/notes/), and the symbolic ref HEAD.
 +
 This information can be used to determine what commit
 was the tip of a branch "2 days ago".
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index e25a65a..18fce69 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -60,8 +60,9 @@ still contains <oldvalue>.
 
 Logging Updates
 ---------------
-If config parameter "core.logAllRefUpdates" is true or the file
-"$GIT_DIR/logs/<ref>" exists then `git update-ref` will append
+If config parameter "core.logAllRefUpdates" is true and the ref is one under
+"refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or
+the file "$GIT_DIR/logs/<ref>" exists then `git update-ref` will append
 a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
 symbolic refs before creating the log name) describing the change
 in ref value.  Log lines are formatted as:
-- 
1.7.5.517.g10515

Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates

[Junio C Hamano]

Bert Wesarg <bert.wesarg@googlemail.com> 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:

	[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

Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates

[Bert Wesarg]

On Mon, Jul 11, 2011 at 19:29, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> 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

Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates

[Junio C Hamano]

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

Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates

[Michael Haggerty]

Minor typo; see below.

On 07/11/2011 11:14 AM, Bert Wesarg wrote:
> 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(-)
> 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index c631d1c..dd44122 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -344,7 +344,9 @@ core.logAllRefUpdates::
>  	SHA1, the date/time and the reason of the update, but
>  	only when the file exists.  If this configuration
>  	variable is set to true, missing "$GIT_DIR/logs/<ref>"
> -	file is automatically created for branch heads.
> +	file is automatically created for branch heads (i.e. under
> +	refs/heads/), remote reafs (i.e. under refs/remotes/),

s/reafs/refs/

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates

[Bert Wesarg]

On Tue, Jul 12, 2011 at 06:39, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Minor typo; see below.
>> +     refs/heads/), remote reafs (i.e. under refs/remotes/),
>
> s/reafs/refs/

Thanks.

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

Bert