git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: 'git merge tag' not working as before

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 30, 2012, 23:12 UTC
Message-ID
<CAMP44s0EQOgEKQ7x1as7HAi0UHcWmJwnuWNYQ9ifpThOLYx5MQ@mail.gmail.com>
In-Reply-To
<7vfwahxqhr.fsf@alter.siamese.dyndns.org>
On Thu, May 31, 2012 at 12:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I used to do things like 'git merge v1.7.10.3' (from v1.7.10.2) but
>> even though it's ff it tries to create a merge commit.
>>
>> Seems like now I have to run 'git merge v1.7.10.3^0', I don't see why
>> that would be desirable.
>>
>> I think this is a bug and a regression.
>
> It was a deliberate feature enhancement a few releases back, IIRC.
>
> You should be able to say "git merge --ff-only v1.7.10.3" as well.
How is that an enhancement?
Basically:
  git merge branch # fast-forward
  git merge tag # fast-forward
  git merge annotated-tag # not fast-forward

Why should I do different actions depending on whether the tag is annotated or not? 99% of users probably have never used annotated tags, why complicate the interface for 99% of users, when the 1% of users who actually want the messages of the annotated tag in their merge message can just do --no-ff?

Cheers.
-- 
Felipe Contreras
Previous: Junio C Hamano
Message 3 of 3 in “'git merge tag' not working as before”
  1. Felipe ContrerasMay 30, 2012
  2. Junio C HamanoMay 30, 2012
  3. Felipe ContrerasMay 30, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.