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

[1.7.9] usage regression when merging annotated tag objects

From
BTBart Trojanowski <bart@jukie.ca>
Date
Feb 3, 2012, 23:08 UTC
Message-ID
<CADeLxZTsq1M5oEb1u5Oqfxq3dYXL6E_uN9bXaTqaOZiA0fgdJQ@mail.gmail.com>

I recently started using git 1.7.9.  Earlier today GregKH released a stable kernel update and I tried my tried and true procedure using 'git merge --ff-only v3.2.3'.  I was a bit surprised with the results.

There are two tags I am toying with...

69bade0 is v3.2.3 3499d64 is v3.2.2

And here is where we start...

$ git describe v3.2.2

$ git merge-base v3.2.2 v3.2.3 | xargs git describe v3.2.2

(it is thus eligible for a fast-forward)
Finally, the strangeness...

$ git merge --ff-only v3.2.3 fatal: Not possible to fast-forward, aborting.

$ git merge --ff-only v3.2.3~ Updating 3499d64..7b171c5 Fast-forward ...

$ git merge --ff-only v3.2.3 fatal: Not possible to fast-forward, aborting.

After talking to Junio, he pointed out that "merging tag objects gained new meanings in 1.7.9".

I am not sure if my confusion will be shared by others and if --ff-only needs a clarification.  Perhaps --ff-only should just continue to work as it did before, and fast-forward from tag to tag.

Cheers, -Bart

Next: Junio C Hamano
Message 1 of 3 in “[1.7.9] usage regression when merging annotated tag objects”
  1. Bart TrojanowskiFeb 3, 2012
  2. Junio C HamanoFeb 3, 2012
  3. merge: do not create a signed tag merge under --ff-only optionJunio C Hamano, Feb 6, 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.