Re: [PATCH v4 01/19] git-rebase.txt: update description of --allow-empty-message

From: Elijah Newren <newren@gmail.com>
Date: Feb 13, 2020, 18:35 UTC
Message-ID: <CABPp-BHgGcp8FzrOGfbp4-5Dzda8v76GRR-8RimWfdMSZOntuQ@mail.gmail.com>
In-Reply-To: <09f2a9bd-1fd2-b44b-a279-baf37ae23391@gmail.com>

Hi Phillip,

On Sun, Feb 9, 2020 at 7:59 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

>
> Hi Elijah
>

...

Show 18 quoted lines

> > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> > index 0c4f038dd6..c83be7ffc2 100644
> > --- a/Documentation/git-rebase.txt
> > +++ b/Documentation/git-rebase.txt
> > @@ -265,9 +265,10 @@ See also INCOMPATIBLE OPTIONS below.
> >   See also INCOMPATIBLE OPTIONS below.
> >
> >   --allow-empty-message::
> > -     By default, rebasing commits with an empty message will fail.
> > -     This option overrides that behavior, allowing commits with empty
> > -     messages to be rebased.
> > +     No-op.  Rebasing commits with an empty message used to fail
> > +     and this option would override that behavior, allowing commits
> > +     with empty messages to be rebased.  Now commits with an empty
> > +     message do not cause rebasing to halt.
>
> Do we want to mention that the user can pass --no-allow-empty-message to
> override this?

Interesting point. I could be persuaded towards that, but I'm leaning against it based on the logic in b00bf1c9a8dd which this commit was based upon.

However, even if we do want to mention --no-allow-empty-message, I'd rather do that in a different series. This patch is already slightly tangential to the series, but it at least fixes the documentation for a previously-documented option -- an option that happens to be similar in spirit to the ones being touched by the series. Adding documentation for a previously undocumented option, while possibly laudable, feels like taking a tangent to a tangent to me. (And this series is already long enough and is still hanging after two months, so...)

Elijah