Re: [PATCH] Documentation: merging a tag is a special case
From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:56:27
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: [PATCH] Documentation: merging a tag is a special case · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH] Documentation: merging a tag is a special case · Jonathan Nieder <hidden>
- 2016-06-15 · Re: [PATCH] Documentation: merging a tag is a special case · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH] Documentation: merging a tag is a special case · Jonathan Nieder <hidden>
- 2016-06-15 · Re: [PATCH] Documentation: merging a tag is a special case · Yann Droneaud <hidden>
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. [...]
quoted hunk ↗ jump to hunk
--- 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. [...]
quoted hunk ↗ jump to hunk
--- 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 <redacted>