git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates
@ 2011-07-11  9:14 Bert Wesarg
  2011-07-11 17:29 ` Junio C Hamano
  2011-07-12  4:39 ` Michael Haggerty
  0 siblings, 2 replies; 6+ messages in thread
From: Bert Wesarg @ 2011-07-11  9:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, 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

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates
  2011-07-11  9:14 [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates Bert Wesarg
@ 2011-07-11 17:29 ` Junio C Hamano
  2011-07-11 18:23   ` Bert Wesarg
  2011-07-12  4:39 ` Michael Haggerty
  1 sibling, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2011-07-11 17:29 UTC (permalink / raw)
  To: Bert Wesarg; +Cc: git

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates
  2011-07-11 17:29 ` Junio C Hamano
@ 2011-07-11 18:23   ` Bert Wesarg
  2011-07-11 21:24     ` Junio C Hamano
  0 siblings, 1 reply; 6+ messages in thread
From: Bert Wesarg @ 2011-07-11 18:23 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates
  2011-07-11 18:23   ` Bert Wesarg
@ 2011-07-11 21:24     ` Junio C Hamano
  0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2011-07-11 21:24 UTC (permalink / raw)
  To: Bert Wesarg; +Cc: git

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates
  2011-07-11  9:14 [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates Bert Wesarg
  2011-07-11 17:29 ` Junio C Hamano
@ 2011-07-12  4:39 ` Michael Haggerty
  2011-07-12 17:03   ` Bert Wesarg
  1 sibling, 1 reply; 6+ messages in thread
From: Michael Haggerty @ 2011-07-12  4:39 UTC (permalink / raw)
  To: Bert Wesarg; +Cc: Junio C Hamano, git

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/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates
  2011-07-12  4:39 ` Michael Haggerty
@ 2011-07-12 17:03   ` Bert Wesarg
  0 siblings, 0 replies; 6+ messages in thread
From: Bert Wesarg @ 2011-07-12 17:03 UTC (permalink / raw)
  To: Michael Haggerty; +Cc: Junio C Hamano, git

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-07-12 17:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-11  9:14 [PATCH] Documentation: clearly specify what refs are honored by core.logAllRefUpdates Bert Wesarg
2011-07-11 17:29 ` Junio C Hamano
2011-07-11 18:23   ` Bert Wesarg
2011-07-11 21:24     ` Junio C Hamano
2011-07-12  4:39 ` Michael Haggerty
2011-07-12 17:03   ` Bert Wesarg

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).