Subject: Re: [PATCH] Documentation: merging a tag is a special case

From: Jonathan Nieder <[email-masked]>
Date: Wed, 20 Mar 2013 11:54:34 -0700

Yann Droneaud wrote:

> When asking Git to merge a tag (such as a signed tag or annotated tag),
> it will always create a merge commit even if fast-forward was possible.
> It's like having --no-ff present on the command line.

Thanks.  This looks good, modulo some nitpicks.

[...]
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -170,6 +170,15 @@ happens:
>  If you tried a merge which resulted in complex conflicts and
>  want to start over, you can recover with `git merge --abort`.
>  
> +MERGING TAG
> +-----------
> +
> +When merging a tag (annotated or signed), Git will create a merge commit

How about something like "When merging an annotated or signed tag" or
"When merging an annotated (and possibly signed) tag"?  The above text
can be misread as meaning "When merging any tag, no matter whether it
is annotated or signed", which is needlessly confusing for people who
don't know about unannotated tags.

[...]
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -26,7 +26,7 @@ set to `no` at the beginning of them.
>  --ff::
>  	When the merge resolves as a fast-forward, only update the branch
>  	pointer, without creating a merge commit.  This is the default
> -	behavior.
> +	behavior (except when merging a tag).

s/a tag/an annotated tag/ here as well.

By the way, what about the possibility of dropping this implicit
--no-ff?  I think Linus could get used to passing --no-ff explicitly
when responding to pull requests.  I could go either way on it.

It is certainly useful to document the current state before
considering changing it, so with the tweaks mentioned above,
Reviewed-by: Jonathan Nieder <[email-masked]>