Dlaczego nie mogę przekazać tego aktualnego poddrzewa Git?

Używam poddrzewa Git z kilkoma projektami, nad którymi pracuję, aby udostępnić między nimi kod podstawowy. Kod podstawowy jest często aktualizowany, a aktualizacje mogą mieć miejsce w każdym z projektów, ostatecznie wszystkie z nich zostaną zaktualizowane.

Napotkałem problem polegający na tym, że git zgłasza, że ​​moje poddrzewo jest aktualne, ale wypychanie zostaje odrzucone. Na przykład:

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

Jeśli nacisnę, powinienem otrzymać wiadomość, że nie ma co naciskać ... Tak? DOBRZE? :(

#! 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.

Co mogłoby być tego przyczyną? Dlaczego pchanie zawodzi?

Znalazłem odpowiedź w tym komentarzu na blogu https://coderwall.com/p/ssxp5q

Jeśli napotkasz problem „Aktualizacje zostały odrzucone, ponieważ końcówka Twojej bieżącej gałęzi jest opóźniona. Scal zmiany zdalne (np.„ Git pull ”)” podczas pchania (z jakiegoś powodu, esp pieprzenie się z historią git) wtedy będziesz musiał zagnieździć polecenia git, aby móc wymusić wypchnięcie na heroku. np. biorąc pod uwagę powyższy przykład:

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

W systemie Windows zagnieżdżone polecenie nie działa:

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

Możesz po prostu najpierw uruchomić zagnieżdżony bit:

git subtree split --prefix pythonapp master

To (po wielu liczbach) zwróci token, np

157a66d050d7a6188f243243264c765f18bc85fb956

Użyj tego w poleceniu zawierającym, np:

git push heroku 157a66d050d7a6188f243243264c765f18bc85fb956:master --force

Użyj --ontoflagi:

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

[EDYCJA: niestety subtree pushnie przesyła dalej --ontodo bazowego split, więc operację należy wykonać w dwóch poleceniach! Po wykonaniu tej czynności widzę, że moje polecenia są identyczne z tymi w jednej z pozostałych odpowiedzi, ale wyjaśnienie jest inne, więc i tak zostawię je tutaj.]

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

Lub jeśli nie używasz basha:

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

Spędziłem godziny, przeglądając źródło poddrzewa git, aby znaleźć to rozwiązanie, więc mam nadzieję, że to docenisz;)

subtree pushzaczyna się od uruchomienia subtree split, które przepisuje historię zmian do formatu, który powinien być gotowy do wysłania. Sposób, w jaki to robi, polega na odcięciu public/shared/początku każdej ścieżki, która go zawiera, i usunięciu wszelkich informacji o plikach, które go nie mają. Oznacza to, że nawet jeśli wyciągniesz niezgniecione, wszystkie zatwierdzenia z repozytorium wyższego szczebla zostaną zignorowane, ponieważ nazywają pliki według ich gołych ścieżek. (Zatwierdzenia, które nie dotykają żadnych plików wpublic/shared/lub zatwierdzenia scalające, które są identyczne z rodzicami, również są zwinięte. [EDYCJA: Poza tym, od tamtej pory znalazłem wykrywanie squasha, więc teraz myślę, że to tylko wtedy, gdy wyciągnąłeś niezgnieciony, a następnie uproszczone zwijanie zatwierdzenia scalającego opisane w kolejnej odpowiedzi pozwala wybrać niezgniecioną ścieżkę i odrzucić zgniecioną ścieżkę.]) Rezultat jest taki, że rzeczy, które próbuje wypchnąć, kończą się zawieraniem pracy, którą ktoś poświęcił na bieżące repozytorium hosta, z którego wypychasz, ale nie pracy osób zaangażowanych bezpośrednio do repozytorium podrzędnego lub za pośrednictwem innego hosta magazyn.

Jeśli jednak użyjesz --onto, wszystkie zatwierdzone zmiany są rejestrowane jako OK, aby używać ich dosłownie, więc gdy proces przepisywania napotka je jako jeden z rodziców scalania, chce je przepisać, zachowa je zamiast próbować je przepisać w zwykły sposób.

W przypadku aplikacji typu „Strony GitHub”, w której wdrażasz poddrzewo „dist” w gałęzi gh-pages, rozwiązanie może wyglądać mniej więcej tak

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

Wspominam o tym, ponieważ wygląda to nieco inaczej niż przykłady heroku podane powyżej. Widzisz, że mój folder „dist” istnieje w głównej gałęzi mojego repozytorium, a następnie przesyłam go jako poddrzewo do gałęzi gh-pages, która również znajduje się w źródle.

Z tym problemem spotkałem się już wcześniej i oto jak go rozwiązałem.

Dowiedziałem się, że mam oddział, który nie był dołączony do lokalnego oddziału głównego. Ta gałąź istnieje i po prostu wisi w próżni. W twoim przypadku prawdopodobnie nazywa się project-shared. Zakładając, że tak jest i kiedy robisz a git branch, możesz zobaczyć lokalny project-sharedoddział, możesz `` dołączyć '' nowe zatwierdzenia do istniejącego project-sharedoddziału, wykonując:

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

Zrozumiałem, git subtreeże zacznę tworzenie nowego oddziału --onto, w tym przypadku jest to public-sharedoddział lokalny . Wówczas gałąź oznacza utworzenie gałęzi, która po prostu zastępuje starą public-sharedgałąź.

Pozwoli to zachować wszystkie poprzednie SHA public-sharedgałęzi. Wreszcie możesz zrobić

git push project-shared project-shared:master

Zakładając, że masz również project-sharedpilota; spowoduje to przesunięcie lokalnego wiszącego w pustej project-shared gałęzi do mastergałęzi pilota project-shared.

Wynika to z ograniczeń oryginalnego algorytmu. Podczas obsługi zatwierdzeń scalających oryginalny algorytm używa uproszczonych kryteriów odcinania niepowiązanych rodziców. W szczególności sprawdza, czy istnieje rodzic, który ma to samo drzewo. Gdyby taki rodzic znalazł, zwinąłby zatwierdzenie scalające i zamiast tego użyłby zatwierdzenia rodzica, zakładając, że inni rodzice mają zmiany niezwiązane z poddrzewem. W niektórych przypadkach spowodowałoby to porzucenie części historii, która ma rzeczywiste zmiany w poddrzewie. W szczególności porzuciłby sekwencje zatwierdzeń, które dotknęłyby poddrzewa, ale skutkowałyby tą samą wartością poddrzewa.

Zobaczmy przykład (który możesz łatwo odtworzyć), aby lepiej zrozumieć, jak to działa. Weź pod uwagę następującą historię (format linii to: zatwierdzenie [drzewo] temat):

% 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

W tym przykładzie dzielimy się dalej dir . Zatwierdza Di Ema to samo drzewo z, ponieważ mamy zatwierdzenie C, które cofnęło zatwierdzenie B, więc B-Csekwencja nie robi nic, dirmimo że ma w niej zmiany.

Teraz zróbmy podział. Najpierw podzieliliśmy się po zatwierdzeniu 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

Następnie podzieliliśmy się po zatwierdzeniu E.

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

Tak, straciliśmy dwa zatwierdzenia. Powoduje to błąd podczas próby wypchnięcia drugiego podziału, ponieważ nie ma on tych dwóch zatwierdzeń, które już dotarły do ​​źródła.

Zwykle możesz tolerować ten błąd używając push --force, ponieważ porzucone zatwierdzenia generalnie nie zawierają krytycznych informacji. Na dłuższą metę błąd musi zostać naprawiony, więc historia splitu faktycznie zawierałaby wszystkie zatwierdzenia, które dotykają dir, zgodnie z oczekiwaniami. Spodziewałbym się, że poprawka obejmie głębszą analizę zatwierdzeń rodzica dla ukrytych zależności.

Dla odniesienia, oto część oryginalnego kodu odpowiedzialna za zachowanie.

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

Odpowiedź Erica Woodruffa mi nie pomogła, ale następujące:

Zwykle używam opcji „git subtree pull” z opcją „--squash”. Wygląda na to, że utrudniło to pogodzenie sprawy, więc musiałem tym razem wyciągnąć poddrzewo bez zgniatania, rozwiązać niektóre konflikty, a następnie naciskać.

Muszę dodać, że zgniecione szarpnięcie nie ujawniło żadnych konfliktów, powiedziało mi, że wszystko w porządku.

Innym [prostszym] rozwiązaniem jest przesunięcie głowy pilota poprzez wykonanie kolejnego zatwierdzenia, jeśli możesz. Po wciągnięciu tej zaawansowanej głowy do lokalnego poddrzewa będziesz mógł ponownie z niej wypchnąć.

Możesz wymusić wypychanie lokalnych zmian do zdalnego repozytorium poddrzewa

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

Szybka powłoka PowerShell dla użytkowników systemu Windows oparta na rozwiązaniu Chrisa Jordana

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

Oto, co napisałem na podstawie tego, co powiedział @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

Miałem też ten problem. Oto, co zrobiłem na podstawie najlepszych odpowiedzi:

Dany:

#! 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.

Wpisz to:

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

Zwróć uwagę, że token wyprowadzany przez „git subtree push” jest używany w „git push”.