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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 20, 2013, 18:54 UTC
Message-ID: <20130320185434.GP3655@google.com>
In-Reply-To: <1363802033-26868-1-git-send-email-ydroneaud@opteya.com>

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.

[...]

Show 10 quoted lines

> --- 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.

[...]

Show 8 quoted lines

> --- 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 <jrnieder@gmail.com>