Почему я не могу отправить это актуальное поддерево Git?

Я использую поддерево Git с парой проектов, над которыми я работаю, чтобы разделить между ними некоторый базовый код. Базовый код часто обновляется, и обновления могут происходить в любом из проектов, и в конечном итоге все они будут обновлены.

Я столкнулся с проблемой, когда git сообщает, что мое поддерево обновлено, но нажатие отклоняется. Например:

#! git subtree pull --prefix=public/shared project-shared master
From github.com:****
* branch            master     -> FETCH_HEAD
Already up-to-date.

Если я нажму, я должен получить сообщение, что толкать нечего ... Верно? ВЕРНО? :(

#! git subtree push --prefix=public/shared project-shared master
git push using:  project-shared master
To git@github.com:***
! [rejected]        72a6157733c4e0bf22f72b443e4ad3be0bc555ce -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:***'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Что могло быть причиной этого? Почему толкать не удается?

Я нашел ответ в этом комментарии блога https://coderwall.com/p/ssxp5q

Если вы столкнулись с проблемой «Обновления были отклонены, потому что кончик вашей текущей ветки позади. Объедините удаленные изменения (например, 'git pull')», когда вы нажимаете (по какой-либо причине, особенно с использованием истории git) тогда вам нужно будет вложить команды git, чтобы вы могли принудительно нажать на heroku. например, учитывая приведенный выше пример:

git push heroku `git subtree split --prefix pythonapp master`:master --force

В Windows вложенная команда не работает:

git push heroku `git subtree split --prefix pythonapp master`:master --force

Вы можете сначала запустить вложенный бит:

git subtree split --prefix pythonapp master

Это (после большого количества чисел) вернет токен, например

157a66d050d7a6188f243243264c765f18bc85fb956

Используйте это в содержащей команду, например:

git push heroku 157a66d050d7a6188f243243264c765f18bc85fb956:master --force

Используйте --ontoфлаг:

# DOESN'T WORK: git subtree push --prefix=public/shared project-shared master --onto=project-shared/master

[РЕДАКТИРОВАТЬ: к сожалению subtree push, не пересылается --ontoна нижележащий split, поэтому операция должна выполняться двумя командами! После этого я вижу, что мои команды идентичны командам в одном из других ответов, но объяснение другое, поэтому я все равно оставлю его здесь.]

git push project-shared $(git subtree split --prefix=public/shared --onto=project-shared/master):master

Или, если вы не используете bash:

git subtree split --prefix=public/shared --onto=project-shared/master
# This will print an ID, say 0123456789abcdef0123456789abcdef,
# which you then use as follows:
git push project-shared 01234567:master

Я часами просматривал исходный код git-subtree, чтобы понять это, так что надеюсь, вы это оцените;)

subtree pushначинается с запуска subtree split, который переписывает вашу историю коммитов в формат, который должен быть готов к отправке. Таким образом, он удаляет public/shared/переднюю часть любого пути, в котором он есть, и удаляет любую информацию о файлах, у которых его нет. Это означает, что даже если вы вытащите без сжатия, все коммиты суб-репозитория в восходящем направлении игнорируются, поскольку они называют файлы своими пустыми путями. (Коммиты, которые не касаются файлов вpublic/shared/, или коммиты слияния, которые идентичны родительским, также сворачиваются. [РЕДАКТИРОВАТЬ: Кроме того, с тех пор я обнаружил некоторое обнаружение сквоша, поэтому теперь я думаю, что это только в том случае, если вы вытащили несжатый, а затем упрощенное свертывание фиксации слияния, описанное в еще одном ответе, позволяет выбрать несжатый путь и отбросьте сжатый путь.]) В результате материал, который он пытается отправить, в конечном итоге содержит любую работу, которую кто-то привязал к текущему репозиторию хоста, из которого вы нажимаете, но не рабочие люди, привязанные непосредственно к суб-репозиторию или через другой хост репозиторий.

Однако, если вы используете --onto, то все восходящие коммиты записываются как ОК для использования дословно, поэтому, когда процесс перезаписи сталкивается с ними как с одним из родителей слияния, он хочет переписать, он сохранит их, а не пытается их переписать. обычным способом.

Для приложения типа «GitHub pages», где вы развертываете поддерево «dist» в ветке gh-pages, решение может выглядеть примерно так

git push origin `git subtree split --prefix dist master`:gh-pages --force

Я упоминаю об этом, поскольку он немного отличается от приведенных выше примеров heroku. Вы можете видеть, что моя папка "dist" существует в главной ветке моего репо, а затем я нажимаю ее как поддерево в ветку gh-pages, которая также находится в источнике.

Я уже сталкивался с этой проблемой раньше, и вот как я ее решил.

Я обнаружил, что у меня есть ветка, которая не была прикреплена к локальной основной ветке. Эта ветка существует и просто висит в пустоте. В вашем случае это, вероятно, называется project-shared. Предполагая, что это так, и когда вы делаете это, git branchвы видите локальную project-sharedветку, тогда вы можете « добавлять » новые коммиты в свою существующую project-sharedветку, выполнив:

git subtree split --prefix=public/shared --onto public-shared --branch public-shared

Как я понял, я git subtreeначну создавать новую ветку --onto, в данном случае это локальная public-sharedветка. Затем ветвь означает создание ветки, которая просто заменяет старую public-sharedветку.

Это сохранит весь предыдущий SHA public-sharedветки. Наконец, вы можете сделать

git push project-shared project-shared:master

Предполагая, что у вас есть project-shared пульт; это подтолкнет локальное зависание в project-shared ветке void к masterветке удаленного project-shared.

Это из-за ограничений исходного алгоритма. При обработке коммитов слияния исходный алгоритм использует упрощенные критерии для отсечения неродственных родителей. В частности, он проверяет, есть ли родитель, у которого такое же дерево. Если такой родитель найден, он свернет фиксацию слияния и вместо нее будет использовать родительскую фиксацию, предполагая, что у других родителей есть изменения, не связанные с поддеревом. В некоторых случаях это может привести к удалению частей истории, в которых есть фактические изменения в поддереве. В частности, он отбрасывает последовательности коммитов, которые касаются поддерева, но приводят к тому же значению поддерева.

Давайте посмотрим на пример (который вы можете легко воспроизвести), чтобы лучше понять, как это работает. Рассмотрим следующую историю (формат строки: коммит [дерево] тема):

% git log --graph --decorate --pretty=oneline --pretty="%h [%t] %s"
*   E [z] Merge branch 'master' into side-branch
|\
| * D [z] add dir/file2.txt
* | C [y] Revert "change dir/file1.txt"
* | B [x] change dir/file1.txt
|/
*   A [w] add dir/file1.txt

В этом примере мы разделяем dir. Коммиты Dи Eимеют то же дерево z, потому что у нас есть фиксация C, которая отменила фиксацию B, поэтому B-Cпоследовательность ничего не делает дляdir даже если в ней есть изменения.

Теперь займемся разделением. Сначала мы разбиваем на коммит C.

% git log `git subtree split -P dir C` ...
* C' [y'] Revert "change dir/file1.txt"
* B' [x'] change dir/file1.txt
* A' [w'] add dir/file1.txt

Затем мы разбиваем на коммит E.

% git log `git subtree split -P dir E` ...
* D' [z'] add dir/file2.txt
* A' [w'] add dir/file1.txt

Да, мы потеряли две фиксации. Это приводит к ошибке при попытке подтолкнуть второе разбиение, поскольку у него нет тех двух коммитов, которые уже попали в источник.

Обычно вы можете допустить эту ошибку, используя push --force, поскольку отброшенные коммиты обычно не содержат в себе важной информации. В долгосрочной перспективе ошибку необходимо исправить, чтобы в истории разделения действительно были все коммиты, которые касаются dir, как и ожидалось. Я ожидаю, что исправление будет включать более глубокий анализ родительских коммитов на предмет скрытых зависимостей.

Для справки, вот часть исходного кода, отвечающая за поведение.

copy_or_skip()
  ...
  for parent in $newparents; do
      ptree=$(toptree_for_commit $parent) || exit $?
      [ -z "$ptree" ] && continue
      if [ "$ptree" = "$tree" ]; then
          # an identical parent could be used in place of this rev.
          identical="$parent"
      else
          nonidentical="$parent"
      fi
  ...
  if [ -n "$identical" ]; then
      echo $identical
  else
      copy_commit $rev $tree "$p" || exit $?
  fi

Ответ Эрика Вудраффа мне не помог, но помогло следующее:

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

Надо добавить, что раздавленная тяга не выявила конфликтов, все в порядке.

Другое [более простое] решение - продвинуть головку пульта ДУ, сделав еще одну фиксацию, если можете. После того, как вы поместите эту расширенную голову в локальное поддерево, вы снова сможете вытолкнуть ее из нее.

Вы можете принудительно отправить локальные изменения в удаленное репозиторий поддерева

git push subtree_remote_address.git `git subtree split --prefix=subtree_folder`:refs/heads/branch --force

Быстрый PowerShell для пользователей Windows на основе решения Криса Джордана

$id = git subtree split --prefix pythonapp master
Write-Host "Id is: $id"
Invoke-Expression "git push heroku $id`:master --force"

Вот что я написал на основе того, что сказал @entheh.

for /f "delims=" %%b in ('git subtree split --prefix [name-of-your-directory-on-the-file-system-you-setup] -b [name-of-your-subtree-branch]') do @set token=%%b
git push [alias-for-your-subtree] %token%:[name-of-your-subtree-branch] --force

pause

Была и эта проблема. Вот что я сделал, основываясь на самых популярных ответах:

Дано:

#! git subtree push --prefix=public/shared project-shared master
git push using:  project-shared master
To git@github.com:***
! [rejected]        72a6157733c4e0bf22f72b443e4ad3be0bc555ce -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:***'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Введите это:

git push <origin> 72a6157733c4e0bf22f72b443e4ad3be0bc555ce:<branch> --force

Обратите внимание, что токен, который выводится командой «git subtree push», используется в «git push».