* [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
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.