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

Re: Unexpected or wrong ff, no-ff and ff-only behaviour

From
Sergey Organov <sorganov@gmail.com>
Date
Jul 10, 2019, 14:36 UTC
Message-ID
<87y316gdnf.fsf@osv.gnss.ru>
In-Reply-To
<CABPp-BHpkcOSkTrNDPGWRgSJgbqkc0PRqMqmesg7tQdS5TfMDA@mail.gmail.com>
Hi Elijah,
Elijah Newren <newren@gmail.com> writes:
Show 18 quoted lines
> Hi Roland,
>
> On Tue, Jul 9, 2019 at 9:17 AM Roland Jäger <eyenseo@mailbox.org> wrote:
>>
>> Thanks for answering Junio.
>>
>> I get what git does. But I believe that either the documentation ist
>> wrong/ambiguous or --no-ff and --ff-only should be able to be
>> combined and either should be fixed - preferably the later. What I
>> want to say to git is "I never accept a real merge; please make a
>> merge commit, even if it is redundant/empty". And I believe that
>> github and gitlab allow to configure something like that.
>
> Please don't top-post on this list.
>
> I agree, the documentation is wrong or misleading and there is a
> wording change we could make to improve it.  But, in particular,
> --no-ff and -ff-only are completely incompatible.
They currently are compatible, but in a weird manner, see below.

I'd prefer they were perfectly compatible and orthogonal, as using both would be the safe way to create cleanest possible merge -- the one that introduces on the mainline the /exact/ changes made on side-branch:

--ff-only: tells git to refuse operation (actual merge) if FF is impossible, that for this particular use-case would ensure the merge, when actually created, is the "cleanest possible" one

and then

--no-ff: forces git to create actual (cleanest possible) merge commit, that otherwise it wouldn't, as it defaults to --ff, and --ff-only above ensures FF is possible.

Right now (in my git 2.10) it seems these options somehow cancel each other, that is both useless and surprising:

When FF is possible:
$ git merge --ff-only --no-ff side_branch

Merge made by the 'recursive' strategy. [...]

Good!

$ git reset --hard HEAD~1 [...] $ git merge --no-ff --ff-only side_branch Updating eafaed6..b83db07 Fast-forward [...]

??? I said --no-ff: how comes you did fast-forward?!
When FF is impossible:
$ git merge --ff-only --no-ff side_branch

Merge made by the 'recursive' strategy. [...] ??? I said --ff-only: how comes you didn't bail out?!

$ git reset --hard HEAD~1 [...] $ git merge --no-ff --ff-only side_branch fatal: Not possible to fast-forward, aborting.

Good!
-- Sergey
git version 2.10.0.1.g57b01a3
Previous: brian m. carlson
Message 20 of 20 in “Unexpected or wrong ff, no-ff and ff-only behaviour”
  1. usbuser@mailbox.orgJul 9, 2019
  2. Junio C HamanoJul 9, 2019
  3. Roland JägerJul 9, 2019
  4. Elijah NewrenJul 9, 2019
  5. usbuser@mailbox.orgJul 9, 2019
  6. Elijah NewrenJul 9, 2019
  7. Bryan TurnerJul 9, 2019
  8. usbuser@mailbox.orgJul 10, 2019
  9. Junio C HamanoJul 10, 2019
  10. Sergey OrganovJul 11, 2019
  11. Junio C HamanoJul 11, 2019
  12. Sergey OrganovJul 12, 2019
  13. Elijah NewrenJul 12, 2019
  14. Sergey OrganovJul 15, 2019
  15. Junio C HamanoJul 12, 2019
  16. Sergey OrganovJul 15, 2019
  17. Junio C HamanoJul 15, 2019
  18. Sergey OrganovJul 19, 2019
  19. brian m. carlsonJul 11, 2019
  20. Sergey OrganovJul 10, 2019

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.