git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] merge-options.txt: clarify meaning of various ff-related options

From
Sergey Organov <sorganov@gmail.com>
Date
Aug 28, 2019, 09:05 UTC
Message-ID
<877e6x3bjj.fsf@osv.gnss.ru>
In-Reply-To
<20190828001307.8042-1-newren@gmail.com>
Elijah Newren <newren@gmail.com> writes:
Show 39 quoted lines
> As discovered on the mailing list, some of the descriptions of the
> ff-related options were unclear.  Try to be more precise with what these
> options do.
>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
> I noticed this patch sitting around in one of my branches, and noticed it
> wasn't upstream.  I'm pretty sure I submitted it a few months back, but I
> think it got lost in the cracks.  Resubmitting and I'll see if I can do a
> better job following up on it.
>
>  Documentation/merge-options.txt | 20 +++++++++++---------
>  1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
> index 79a00d2a4a..b39df5f126 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -40,20 +40,22 @@ set to `no` at the beginning of them.
>  	case of a merge conflict.
>  
>  --ff::
> -	When the merge resolves as a fast-forward, only update the branch
> -	pointer, without creating a merge commit.  This is the default
> +	When the merge can resolve as a fast-forward, do so (only
> +	update the branch pointer to match the merged branch; do not
> +	create a merge commit).  When a fast forward update is not
> +	possible, create a merge commit.  This is the default
>  	behavior.
>  
>  --no-ff::
> -	Create a merge commit even when the merge resolves as a
> -	fast-forward.  This is the default behaviour when merging an
> -	annotated (and possibly signed) tag that is not stored in
> -	its natural place in 'refs/tags/' hierarchy.
> +	Create a merge commit even when the merge could instead resolve
> +	as a fast-forward.  This is the default behaviour when merging
> +	an annotated (and possibly signed) tag that is not stored in its
> +	natural place in 'refs/tags/' hierarchy.

Please notice that virtually all the other cases of --something/--no-something are formatted like this:

--something::
--no-something::
        [descriptions]

So, even only for consistency, it seems to be better to have this the same way:

  --ff::
  --no-ff::
  --ff-only::
        [descriptions]

that, as a bonus, will make it explicit and crystal clear that these 3 things are alternatives, and thus the last one on the command line takes precedence.

-- Sergey
Previous: Elijah NewrenNext: Elijah Newren
Message 2 of 16 in “merge-options.txt: clarify meaning of various ff-related options”
  1. merge-options.txt: clarify meaning of various ff-related optionsElijah Newren, Aug 28, 2019
  2. Sergey OrganovAug 28, 2019
  3. merge-options.txt: clarify meaning of various ff-related optionsElijah Newren, Aug 28, 2019
  4. Martin ÅgrenAug 28, 2019
  5. Sergey OrganovAug 28, 2019
  6. Martin ÅgrenAug 28, 2019
  7. Sergey OrganovAug 29, 2019
  8. Elijah NewrenAug 28, 2019
  9. Sergey OrganovAug 29, 2019
  10. merge-options.txt: clarify meaning of various ff-related optionsElijah Newren, Aug 28, 2019
  11. Junio C HamanoAug 30, 2019
  12. Eric SunshineAug 30, 2019
  13. merge-options.txt: clarify meaning of various ff-related optionsElijah Newren, Aug 31, 2019
  14. Junio C HamanoAug 30, 2019
  15. Elijah NewrenAug 30, 2019
  16. Junio C HamanoAug 30, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.