为何git merge-base命令的结果具有非确定性？

这是我针对合并冲突调试的跟进提问。为简化场景，以下脚本可重复构建完全相同的仓库：

#!/bin/bash

set -Eeuo pipefail

# Start with a new repo in an empty directory
rm -rf git-demo
mkdir git-demo
cd git-demo
git init .
echo 1 >foo
git add foo
git commit -m "foo=1 on main"

# Create two branches off that first commit
git checkout -b feature1
git checkout main
git checkout -b feature2

# Set foo to 2 on feature2
echo 2 >foo
git commit -a -m "foo=2 on feature2"

# Merge feature2 onto main
git checkout main
git merge --no-ff feature2 -m "feature2 -> main"

# Create a dummy commit on feature1
git checkout feature1
echo 1 >dummy
git add dummy
git commit -m "dummy=1 on feature1"

# Merge the dummy commit to main
git checkout main
git merge --no-ff feature1 -m "feature1 -> main"

# Increase foo on feature1
git checkout feature1
echo 3 >foo
git commit -a -m "foo=3 on feature1"

# Merge feature2 onto feature1, using feature1's foo value
git merge --no-ff feature2 || true # Conflicts
git checkout foo --ours
git add foo
git commit -m "feature2 -> feature1"

# Show the merge base of main and feature1
git show -s --oneline $(git merge-base main feature1)

重复运行该脚本时，git merge-base main feature1的输出大多为提交foo=2 on feature2，但偶尔会变为dummy=1 on feature1。给git merge-base添加--all参数会同时列出这两个提交，但输出顺序不固定（不加--all时仅返回列表中的第一个提交），git show-branch --merge-base的输出顺序也和它一致。

我清楚这两个提交都是有效的合并基准，且彼此之间没有祖先关系，地位完全平等。但当dummy=1 on feature1被选为合并基准时，main分支的最新提交（foo值为2）、feature1分支的最新提交（foo值为3）与该基准提交（foo值为1）的foo内容均不相同——这正是我原问题中会引发冲突的场景，但此处不仅没有触发冲突，还出现了这种意外的非确定性行为。

git merge-base的官方文档并未提及任何可能存在的非确定性。

内容的提问来源于Stack Exchange，提问作者Florian Brucker