git-merge: --no-commit is not respected on a fresh repository

## What did you do before the bug happened? (Steps to reproduce your issue)

When trying to perform a subtree merge, especially following the blog post on https://nuclearsquid.com/writings/subtree-merging-and-you/, I noticed that Git does not respect the --no-commit option if the repository does not have a history.

1. Create a new repository: $ git init
2. Add a remote: $ git remote add foo ../<path-to-another-repo>
3. Fetch everything: $ git fetch --all
4. Initiate a subtree merge: $ git merge -s our --no-commit foo/main

## What did you expect to happen? (Expected behavior)

The repository should've been in the "merging" state, in order to rewrite the paths using:

$ git read-tree --prefix=/project/ -u foo/main

It's only a minor annoyance that can be fixed by adding an empty commit in advance of performing the merge, yet it took me some minutes to figure out why Git does not behave as intended.

## What happened instead? (Actual behavior)

A merge commit was created.

## What's different between what you expected and what actually happened?

Said merge commit, even though the `--no-commit` option was set.

[System Info] git version: git version 2.44.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.7.10-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Mar 18 18:56:52 UTC 2024 x86_64 compiler info: gnuc: 13.2 libc info: glibc: 2.38 $SHELL (typically, interactive shell): /usr/bin/fish