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

From: Shawn Pearce <[email-masked]>
Date: Thu, 14 Dec 2006 15:02:45 -0500

Junio C Hamano <[email-masked]> wrote:
> Nicolas Pitre <[email-masked]> 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.

--