On Wed, Feb 01, 2017 at 02:30:38PM -0800, Junio C Hamano wrote:
> > Notes:
> > In a previous discussion (<xmqqbmunrwbf.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>) 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