git команда sparseCheckout и rev-list

Question

Я пытаюсь использовать команду git rev-list в репо, для которого я настроил редкий чек. Репо был настроен следующим образом:

mkdir -p /opt/apcu
git -C /opt/apcu/ init
git -C /opt/apcu/ remote add -f origin git@github.com:krakjoe/apcu.git
git -C /opt/apcu/ config core.sparseCheckout true
echo "apc.php" >> /opt/apcu/.git/info/sparse-checkout
git -C /opt/apcu/ config branch.master.remote origin
git -C /opt/apcu/ config branch.master.merge refs/heads/master
git -C /opt/apcu/ pull origin

Теперь я хотел бы проверить наличие изменений в репо:

$ git rev-list HEAD...origin
fatal: ambiguous argument 'HEAD...origin': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

Есть идеи, почему я получаю вышеуказанную ошибку?

Это сценарий bash, который мне не удался. Идея состояла в том, чтобы проверить наличие изменений в удаленных репозиториях, а затем снять их. Причина, по которой я go проверяет коммиты, заключается в том, что другая функция в сценарии запускает установку в зависимости от того, что обновлено.

# Do not fetch or pull "master" this is not always the default branch you have checked out.
# Omitting the branch to fetch or pull will pull the default.
for i in "${repo_array[@]}"; do
    git -C "$i" fetch origin &>/dev/null
    # Get rid of errors because git reports differences in repo as errors.
    commits=$(git -C "$i" rev-list HEAD...origin --count 2>/dev/null)

    if (( commits != 0 )); then
        git -C "$i" pull origin &>/dev/null
        # Run the installer function to install new versions
        installer
    fi
done 

Answer 1

origin - это не ссылка, а удаленный URL

Например: origin/master будет ссылкой на последний удаленный удаленный master HEAD.

git rev-list HEAD...origin/master

В вашем случае, поскольку master не всегда ветвь, которую вы тянете, вы должны использовать:

commits=$(git -C "$i" rev-list HEAD...@{u} --count 2>/dev/null)

, где @{u} (или @{upstream}) - это ярлык для восходящей ветви, связанной с текущей веткой .

Answer 2

Обратите внимание, что origin может означает origin/HEAD, что может быть символической c ссылкой, указывающей на одно из других origin/* имен удаленного отслеживания. Если origin/HEAD существует, и вы используете имя origin само по себе, как вы делаете, ¹ См. документацию по gitrevisions и, в частности, шестиэтапный процесс разрешения спецификатор ревизии; обратите внимание, что шаг 6 состоит из добавления ref/remotes/ впереди и /HEAD в конце любого имени, которое вы указали, и попытки его поиска.

Запустив git remote add origin, вы можете запустить git remote set-head origin (с любыми параметрами), чтобы установить ссылку refs/remotes/origin/HEAD symboli c. Но если вы действительно не хотите запросить у пульта Git, чтобы ваш refs/remotes/origin/HEAD соответствовал их HEAD, почти наверняка намного лучше просто использовать явный origin/master или origin/other-specified-name, Вот. На самом деле, в сценарии целесообразно использовать полные имена: например, refs/remotes/origin/master.

Использование модификатора @{upstream} или @{u} для имени ветви, вероятно, является лучшим выбором. ; см. Von C ответ .

---

¹ Спецификаторы в составном элементе, такие как HEAD..origin, составляют три токена: HEAD, .. и origin. Под «самим собой» я подразумеваю, что вы используете origin как токен таким образом, а не как часть большего токена, такого как origin/master. Вы также можете написать, например, origin~12 здесь; три токена origin, ~ и 12. Хотя синтаксический анализатор Git является ad-ho c, а не использует формальную грамматику с лексемами , он функционирует как единое целое.