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

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

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

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

[EDIT: к сожалению, 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/, или сливаются коммиты, идентичные родителю, также сворачиваются.[EDIT: Кроме того, с тех пор я нашел некоторое обнаружение сквоша, так что теперь я думаю, что это только в том случае, если вы вытащили не сквош, а затем упрощенное сворачивание коммита слияния, описанное в еще одному ответу удается выбрать не сжатый путь и отбросить сжатый путь.]) В результате материал, который он пытается отправить, в конечном итоге содержит любую работу, которую кто-то передал в текущий репозиторий хоста, из которого вы выталкиваете, но не работает люди, переданные непосредственно в подрепозиторий или через другой хост-репозиторий.

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

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

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

Я упоминаю об этом, так как он немного отличается от приведенных выше примеров героку. Вы можете видеть, что моя папка «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 в ветку master удаленной project-shared.

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

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

% 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 push --prefix=public/shared project-shared master
git push using:  project-shared master
To [email protected]:***
! [rejected]        72a6157733c4e0bf22f72b443e4ad3be0bc555ce -> master (non-fast-forward)
error: failed to push some refs to '[email protected]:***'
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'.

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

Обычно я использую 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