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

octopus merge --no-ff claims to fast-forward even though it doesn't

From
Samuel Lijin <sxlijin@gmail.com>
Date
Jan 27, 2017, 20:46 UTC
Message-ID
<CAJZjrdWdRGZ5DC1XV_YiNt-1sKiNgAtiS-eS9L6H2GJ+_8n08w@mail.gmail.com>

I was doing an octopus merge earlier and noticed that it claims to fast-forward when you specify --no-ff, even though it does actually abide by --no-ff.

I can consistently reproduce as follows:
$ git clone https://github.com/sxlijin/merge-octopus-experiment
$ cd merge-octopus-experiment
$ git merge --no-ff origin/A origin/B --no-edit
Fast-forwarding to: origin/A
Trying simple merge with origin/B
Merge made by the 'octopus' strategy.
 anotherA | 0
 anotherB | 0
 otherA   | 0
 otherB   | 0
 4 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 anotherA
 create mode 100644 anotherB
 create mode 100644 otherA
 create mode 100644 otherB
$ git log --graph --pretty=oneline --decorate

I've reproduced the issue with 2.11.0 on both a Windows box (MSYS) and Linux (Arch).

The issue seems to live in git-merge-octopus.sh, specifically in that --no-ff does not affect the initial value of NON_FF_MERGE. I'm happy to submit a patch if someone can point me in the right direction.

Sam
Next: Junio C Hamano
Message 1 of 2 in “octopus merge --no-ff claims to fast-forward even though it doesn't”
  1. Samuel LijinJan 27, 2017
  2. Junio C HamanoJan 27, 2017

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.