Junio C Hamano <junkio@xxxxxxx> wrote: > Nicolas Pitre <nico@xxxxxxx> writes: > > > 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. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html