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 <jrnie...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
