Как эффективно найти новейшую общую фиксацию ветки при запуске хука предварительного получения сервера?

Сделать это правильно во всех случаях — от «очень сложно» до «невозможно», потому что git push может получать запросы на изменение, добавление и/или несколько имен веток за один раз. То есть только потому, что ваш принимающий Git имеет ветки с именами foo, qqaz и bar, идентифицирующие коммиты 1, 10 и 4 соответственно, теперь не означает, что это произойдет, когда отправка завершится: он может содержать запрос на установку foo в коммит 0, чтобы добавить новый коммит 11 и установить qqaz, чтобы указать на этот коммит, чтобы добавить несколько новых коммитов после 4 и обновить bar, и так далее.

Однако если вы ограничите git push одним обновлением имени ветки — что вы можете сделать, если контролируете различные хуки — проблема станет значительно более разрешимой. Хитрость заключается в том, чтобы распознать, что сам хук pre-receive запускается до того, как будут сделаны какие-либо изменения в именах ветвей. Если baz — это новое имя ветки, то во всех именах веток в репозитории еще нет имени для коммита 7. (Может уже быть имя тега для любого из этих коммитов или создание или обновление имени тега. в списке ссылок, которые будут обновлены этим толчком: обязательно учитывайте их при разработке своего алгоритма.)

Если мы этим воспользуемся, то:

• в запросе push есть строка вида 000...000 <hash-of-7> refs/heads/baz, указывающая, что имя ветки baz будет добавлено, если этот push будет принят;
• git rev-list <hash-of-7> --not --branches --topo-order перечислит коммиты 7, 6 и 5 в указанном порядке;
• родителем 5 является 3.

Если в новой последовательности коммитов есть коммиты слияния, все становится сложнее:

---0---1                   foo
        \
         \   8---9---10    qqaz
          \ /
           2---3---4       bar
            \   \
             ----5
                  \
                   6---7   baz

Здесь коммит 5 представляет собой слияние, объединяющее коммиты 2 и 3. Я не уверен, какие коммиты вы хотите найти в этом случае.

В общем, когда вы хотите изучить график коммитов, git rev-list — это инструмент Git для этого. Параметр --branches указывает использовать все имена веток; --tags указывает использовать все имена тегов; --all говорит использовать все ссылки. --not в параметрах делает последующие ссылки «отрицательными ссылками», как если бы вы указали, скажем, ^refs/heads/dev для исключения ветви dev.¹ Вы также можете указать определенные шаблоны для включения или исключения. Подробнее см. документацию по git rev-list.

¹Позднее --not отменяет более раннее, так что:

git rev-list HEAD --not br1 br2 br3 --not br4

означает то же самое, что:

git rev-list HEAD ^br1 ^br2 ^br3 br4

и вообще порядок положительных и отрицательных ссылок не имеет значения.

Немного сложно, но должно дать правильный результат:

git rev-list baz | grep -Ff <(git rev-list foo qqax bar) | head -1

Если ваша оболочка не понимает оператор <(...), вы можете использовать временный файл:

git rev-list foo qqax bar > /tmp/commit-list.txt
git rev-list baz | grep -Ff /tmp/commit-list.txt | head -1

Другой способ может состоять в том, чтобы последовательно взять merge-base из baz и целевые ветки и сохранить последние из этих коммитов.