Why does git pull always create a merge commit, even if there were no edits between pull A and pull B?

Question

git

I can't solve the dilemma.

Usually there is no such problem, but on two servers, when pulling, git requires you to enter a commit message, and if you compare the commit that arrived from the remote repository with this new commit, then there are no differences between them.

As a result, with each pool, the local branch begins to overtake the remote one by one.

Perhaps something with the git config?
Tried playing around with `core.autocrlf` and `core.filemode` didn't work

color.ui=true
core.autocrlf=false
core.filemode=false
merge.ff=no
user.name=***
user.email=***
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.autocrlf=false
[email protected]***.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

I'd really like an explanation for this behavior rather than fixing the consequences.
Thank you very much for advice like git reset or git pull -ff, but these are not really answers to the question.

Answer 1

if you compare a commit that arrived from a remote repository with this new commit, then there are no differences between them.

You probably wanted to say if you compare a tree , not a commit.
Merging two branches always requires a merge when one of them is not a direct descendant of the other. And it does not depend on whether the trees are the same. Those. to merge such branches, you do not need to merge:

o--A
   `--B

o--A--B--M1--E
    \   /     \
     -C----D---M2--F

And to merge such - you need

o--A--B
   `--B

although the status of both branches is identical.
See what happens in your case, if I understand correctly:

o--A--M1
     /
...-B----C

Neither branch is a descendant of another: C grows from B, not from M1, M1 grows from B and not from C. Therefore, in the future, merging will be required again when merging in any direction.