Почему при git pull всегда создается merge commit, даже если правок между pull A и pull B не было?

Question

[Александр Карпов]

Не могу решить дилемму.

Обычно такой проблемы нет, но вот на двух серверах при pull-е git требует ввести commit message, при этом если сравнить commit прилетевшим с удаленного репозитория с этим новым commit, то отличий между ними нет.

По итогу при каждом пуле локальная ветка начинает обгонять удаленную на единицу.

Возможно что-то с конфигурацией git?
Пробовал играться с `core.autocrlf` и `core.filemode` не помогло

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
remote.origin.url=git@***.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

Мне бы очень хотелось объяснений такого поведения, а не исправления последствий.
Спасибо большое за советы в духе git reset или git pull -ff, но это не совсем ответы на вопрос.

Comments

[Lynn «Кофеман»]

git pull --ff

Answer 1

[jcmvbkbc]

если сравнить commit прилетевшим с удаленного репозитория с этим новым commit, то отличий между ними нет.

Ты наверно хотел сказать, если сравнить дерево, а не коммит.
Чтобы слить две ветки всегда требуется мёрж, когда одна из них не прямой потомок другой. И это не зависит от того, одинаковы ли деревья. Т.е. чтобы слить такие ветки мёрж не нужен:

o--A
   `--B

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

А чтобы слить такие -- нужен

o--A--B
   `--B

хотя состояние обеих веток идентичное.

Смотри, что получается в твоём случае, если я правильно понял:

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

Ни одна ветка не является потомком другой: С растёт из B, а не из M1, M1 растёт из B а не из C. Поэтому в будущем опять потребуется мёрж при объединении в любую сторону.

Comments

[Александр Карпов]

Чтобы слить две ветки всегда требуется мёрж

да, солидарен. Мерж и делается при git pull, однако обычно такой мерж даже не отображается в дереве коммитов.

То что ты описываешь очень похоже на ситуацию с которой столкнулся я.
Т.е. он реально не понимает, что ветка является потомком (фактически это одна и та же ветка и других не было даже).

Вообще ошибка воспроизводится непосредственно у проекта, а не на сервере.

[jcmvbkbc]

Чтобы слить две ветки всегда требуется мёрж

да, солидарен.

Это не то что я сказал.

Мерж и делается при git pull, однако обычно такой мерж даже не отображается в дереве коммитов.

Если твоя локальная ветка -- предок ветки из которой идёт pull, то есть выбор: сделать fast forward или сделать честный мёрж. fast forward -- это просто копирование истории из удалённой ветки. Мёрж -- это новый коммит в твоей ветке, отсутствующий в удалённой ветке. Если сделать честный мёрж к себе хотя бы раз, то потом, если не смёржить свою историю обратно в удалённую ветку, прийдётся делать мёрж каждый раз при git pull.

[Александр Карпов]

jcmvbkbc, спасибо тебе. я нашел проблему.

1. При настройке окружения реально проставили git config merge.ff no - это первопричина такого поведения. Т.е. это не произошло само собой. (нашел в .bash_history)

2. На компе у меня тоже такая конфигурация (это просто совпадение, так сложилось и я разобрался почему, по ошибке когда-то задал вместо локального конфига - глобально)

3. Но я долгое время я не сталкивался с тем что так отконфигурировал git глобально, т.к. я пользуюсь git bash внутри терминала phpstorm (shell path: "C:\Program Files\Git\bin\sh.exe" -login -i) и при работе в нём почему-то всё работает как при merge.ff true, хотя git config --list выдыет no).

Почему git config merge.ff no не работает в последнем случае - это уже другая история.

Вообще ситуация получилась сугубо личной и кажется не имеет никакой пользы для сообщества.