From: Junio C Hamano Date: Wed, 20 Mar 2013 19:07:35 GMT Subject: Re: [PATCH] Documentation: merging a tag is a special case Message-ID: <7vboadevpk.fsf@alter.siamese.dyndns.org> In-Reply-To: <1363802033-26868-1-git-send-email-ydroneaud@opteya.com> Yann Droneaud writes: > 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. > > It's a difference from the default behavior described in git-merge.txt. > It should be documented as an exception of "FAST-FORWARD MERGE" section > and "--ff" option description. > > Signed-off-by: Yann Droneaud > --- > Documentation/git-merge.txt | 9 +++++++++ > Documentation/merge-options.txt | 2 +- > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt > index c852a26..84bc873 100644 > --- 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 > +even if a fast-forward merge is possible (see above). > +The commit message template will be created from the tag message. > +Additionally, the signature check will be reported as a comment > +if the tag was signed. See also linkgit:git-tag[1]. > + It would make it more helpful to readers to describe how _not_ to create such a merge commit if it is unwanted, and how the request to merge a tag interacts with --ff-only option. > HOW CONFLICTS ARE PRESENTED > --------------------------- > > diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt > index 0bcbe0a..70d1ec0 100644 > --- 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). With this update, the reader will be left wondering what would be the default when she asks Git to merge a tag, no? > --no-ff:: > Create a merge commit even when the merge resolves as a