Re: What's in git.git (stable)

Nicolas Pitre [off-list ref] writes:

That changes what the command does to existing repositories,
which is somewhat impolite.

I am not opposed too much to an updated version of the tool that
sets the configuration on by default for newly created
repositories, though.

On Thu, 14 Dec 2006, Shawn Pearce wrote:

Junio C Hamano [off-list ref] wrote:

quoted

That changes what the command does to existing repositories,
which is somewhat impolite.

Yes, but users are forgetting to enable them.  They will work in
a new repository having that feature, move to an older one and not
have it, but expect it to be there.

I concur entirely.

quoted

I am not opposed too much to an updated version of the tool that
sets the configuration on by default for newly created
repositories, though.

I almost did that in my patch - but decided against it for the
reason I just noted above.

Does anyone on the mailing list really have an objection to having
reflogs on by default?

I certainly don't.

Shawn Pearce wrote:

About the only trouble that can cause is a failed push when
git-receive-pack needs to generate the reflog entry but cannot
get the user's committer data because their gecos information
doesn't exist.

In that case, it would be best if it let the commit go through using 
only the username. Reflogs are fixable afterwards, so there's no real 
harm done.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

On Thu, 14 Dec 2006, Junio C Hamano wrote:

Nicolas Pitre [off-list ref] writes:

quoted

I'd say screw that.  The solution should really be this patch:

diff --git a/environment.c b/environment.c
index 84d870c..98275b2 100644
--- a/environment.c
+++ b/environment.c

@@ -15,7 +15,7 @@ int use_legacy_headers = 1;
 int trust_executable_bit = 1;
 int assume_unchanged;
 int prefer_symlink_refs;
-int log_all_ref_updates;
+int log_all_ref_updates = 1;
 int warn_ambiguous_refs = 1;
 int repository_format_version;
 char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";

That changes what the command does to existing repositories,
which is somewhat impolite.

You must be kidding, aren't you?

Just in case you really are serious, let's pretend that being impolite 
for something that has the potential of saving people's arses is 
certainly worth it, much more that the little inconvenience of having 
log files mysteriously appear and make no harm otherwise.

I am not opposed too much to an updated version of the tool that
sets the configuration on by default for newly created
repositories, though.

Hmmm....

Well it is just that I strongly believe users with existing repos have 
no really valid reason to not have this feature enabled.  But making it 
on in a default config file at repo creation time is better than 
nothing.

Junio C Hamano [off-list ref] wrote:

Andreas Ericsson [off-list ref] writes:

quoted

Shawn Pearce wrote:

quoted

About the only trouble that can cause is a failed push when
git-receive-pack needs to generate the reflog entry but cannot
get the user's committer data because their gecos information
doesn't exist.

In that case, it would be best if it let the commit go through using
only the username. Reflogs are fixable afterwards, so there's no real
harm done.

This sounds sensible, regardless of the current discussion on
the default 'logallrefupdates' setting.

Volunteers?

Its a good idea.  I'll do it later tonight, after dinner.

-- 

Junio C Hamano [off-list ref] wrote:

Nicolas Pitre [off-list ref] writes:

quoted

I'd say screw that.  The solution should really be this patch:

diff --git a/environment.c b/environment.c
index 84d870c..98275b2 100644
--- a/environment.c
+++ b/environment.c

@@ -15,7 +15,7 @@ int use_legacy_headers = 1;
 int trust_executable_bit = 1;
 int assume_unchanged;
 int prefer_symlink_refs;
-int log_all_ref_updates;
+int log_all_ref_updates = 1;
 int warn_ambiguous_refs = 1;
 int repository_format_version;
 char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";

That changes what the command does to existing repositories,
which is somewhat impolite.

Yes, but users are forgetting to enable them.  They will work in
a new repository having that feature, move to an older one and not
have it, but expect it to be there.

As I recall the primary objection to enabling them by default
when I first introduced them was that core.logAllRefUpdates=true
meant that refs/tags/<name> were also being logged.  This was not a
great idea as tags generally did not change once they were created.
You fixed that and now it just makes sense to enable it for branch
heads all of the time.

I am not opposed too much to an updated version of the tool that
sets the configuration on by default for newly created
repositories, though.

I almost did that in my patch - but decided against it for the
reason I just noted above.

Does anyone on the mailing list really have an objection to having
reflogs on by default?

About the only trouble that can cause is a failed push when
git-receive-pack needs to generate the reflog entry but cannot
get the user's committer data because their gecos information
doesn't exist.

-- 

Andreas Ericsson [off-list ref] writes:

Shawn Pearce wrote:

quoted

About the only trouble that can cause is a failed push when
git-receive-pack needs to generate the reflog entry but cannot
get the user's committer data because their gecos information
doesn't exist.

In that case, it would be best if it let the commit go through using
only the username. Reflogs are fixable afterwards, so there's no real
harm done.

This sounds sensible, regardless of the current discussion on
the default 'logallrefupdates' setting.

Volunteers?