From: Jeff King <peff@peff.net>
Date: Wed, 01 Feb 2017 22:35:21 GMT
Subject: Re: [PATCH] doc: add note about ignoring --no-create-reflog
Message-ID: <20170201223520.b4er3av67ev5m3ls@sigill.intra.peff.net>
In-Reply-To: <xmqq4m0do86p.fsf@gitster.mtv.corp.google.com>

On Wed, Feb 01, 2017 at 02:30:38PM -0800, Junio C Hamano wrote:

> > Notes:
> >     In a previous discussion (<xmqqbmunrwbf.fsf@gitster.mtv.corp.google.com>) it
> >     was found that git-branch and git-tag accept a "--no-create-reflog" argument,
> >     but it has no effect, does not produce a warning, and is undocumented.
> 
> Reading what Peff said in the thread, I do not think we actively
> wanted this behaviour; we agreed that it is merely acceptable.
> 
> So perhaps s/this behaviour is intentional/this is known/ to weaken
> the log message?  That way, when somebody else who really cares
> comes later and finds this commit that adds explicit notes to these
> manual pages via "git blame", s/he would not be dissuaded from
> making things better.  Such an update may make it warn when
> core.logallrefupdates is not set to false (and continue to ignore
> the command line option), or it may make the command line option
> actually override the configured default.

Yeah, I'd consider it more of a "known bug" or "known limitation" than
anything.

Those can go in a separate section, but they're probably more likely to
be read when supplied next to the actual option.

> With such an update to the log message, I think the patch looks
> good.
> [...]
> > @@ -91,6 +91,7 @@ OPTIONS
> >  	based sha1 expressions such as "<branchname>@\{yesterday}".
> >  	Note that in non-bare repositories, reflogs are usually
> >  	enabled by default by the `core.logallrefupdates` config option.
> > +	The negated form `--no-create-reflog` is silently ignored.

This might be nitpicking, but it's _not_ ignored. It still negates an
earlier "--create-reflog". It is only that it does not override the
decision to create a reflog caused by the setting of
core.logallrefupdates.

-Peff