Alternatywny sposób na zrobienie pierwszego dużego repozytu

Question

Mam ogromną aplikację Rails 3.1 w fazie projektowania i produkcji, na którą ustawiłem tylko środowisko testowe na Heroku. Ponieważ moje repozytorium git jest dość duże, za każdym razem, gdy próbuję pchać, otrzymuję czasowe błędy przy około 33%.

Czy istnieje alternatywa dla zrobienia git push staging master dla tego początkowego gigantycznego popchnięcia?

Komunikat o błędzie jest

EmBP-2:Appname Emma$ git push staging master 
Counting objects: 17421, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (6363/6363), done. 
Connection to 10.10.18.33 closed by remote host.46 KiB/s  
error: pack-objects died of signal 13 
error: failed to push some refs to 'git@heroku.com:appname-staging.git' 

/////////////////// ROZWIĄZANIE/EDIT, wiele miesięcy później ...

Jest podstępny sposób na rozwiązanie tego, obecnie, przy użyciu funkcji Pipoku Heroku (eksperymentalnego), jeśli już masz skonfigurowane środowisko, do którego wepchnąłeś kod. Od Heroku docs:

"Na przykład możesz przesłać kod na etapy, dodać go do ślimaka, a następnie wypromować odrzutowiec do produkcji."

Trwa około 5 sekund, aby Heroku przepchnął istniejący ślimak z jednej aplikacji do drugiej!

Answer 1

Alternatywą jest rozbicie gigantycznego zaangażowania na wiele małych. Tag lub gałąź, zanim to zrobisz. Każda z nich będzie zawierała pewną liczbę plików, które stanowią uzasadnione działanie. Utwórz gałąź temp, która wskaże końcówkę. Teraz zresetuj urządzenie główne do pierwszego z tych mniejszych zatwierdzeń. Pchać. Ustaw master na następny commit. Pchać. Powtarzaj tę czynność, aż skończysz.

Teraz przywróć wzorzec do miejsca, w którym był pierwotnie. Już przeniosłeś obiekty. Pchnięcie tego dużego zatwierdzenia nie powinno ponownie wysyłać wszystkich obiektów, które już istnieją na pilocie.

Answer 2

Nie, jedynym sposobem, aby uzyskać zawartość na Heroku jest przez naciśnięcie git.

Z ciekawości, jak duży jest twój folder projektu?

Answer 3

starałem się pchnąć kilka zmian z filmami i otrzymała:

fatal: The remote end hung up unexpectedly 
error: pack-objects died of signal 13 
error: failed to push some refs to 'git@github.xxxx/XXX.git' 

Rozwiązanie dla mnie było:

git repack 
git push 

nadzieję, że pomoże

Answer 4

za odpowiedź Adama, można rozpakuj swoje duże pchnięcie, zawierające wiele commitów (i ich blobów) na wiele mniejszych paczek, z których każda zawiera podzbiór wymaganych zatwierdzeń dla historii twojej gałęzi.

Zrobiłem to wcześniej, przerywając pełny zestaw zatwierdzeń w blokach, używając tymczasowych gałęzi lub znaczników, ale moje późniejsze próby wykorzystują skrypt wbudowany poniżej. Nie muszę przenosić HEAD ani modyfikować indeksu lub kopii roboczej.

Najpierw musisz zastanowić się, jak agresywny będziesz pod względem liczby zatwierdzeń dla każdego wypychania - większa liczba zatwierdzeń za naciśnięcie może być nieco większa, ale wiąże się z większym ryzykiem trafienia w ten sam problem . Ponieważ twoje zatwierdzenia będą miały różne rozmiary, niektóre okresy w historii mogą zawierać zatwierdzenia o rozmiarze większym niż przeciętny, więc niektóre bloki mogą się powieść, podczas gdy inne wymagają dalszego dzielenia. Możesz również stwierdzić, że masz jedno zatwierdzenie, którego nie można wypchnąć, a to wymaga innego rozwiązania.

Aby przesunąć do nowego zdalnego oddziału master uruchom

git log --reverse --oneline | sed -n '0~100p' | awk '{print "git push staging "$1":refs/heads/master"}' | while read i; do eval $i; done 

Każde przyciśnięcie pchnie następne 100 zobowiązuje, a jedynie musi naciskać nowych obiektów (lub delta) stwierdzono w tej partii zobowiązuje. Wreszcie, trzeba wcisnąć obecny HEAD naciskać na pozostałą część zatwierdzeń i utworzyć ostateczną zdalnego oddziału:

git push staging HEAD:master