Il push di un repository Git esistente su Github invia solo circa la metà dei commit?

Question

Ho un repository Git locale in cui sto sviluppando da alcuni giorni: finora ha fatto diciotto commit. Stasera ho creato un repository Github privato in cui speravo di spingerlo; tuttavia, quando lo feci, finì per spingere solo otto dei diciotto commessi a Github. Ho eliminato il repository Github e riprovato, con lo stesso risultato.

Qualche idea sul perché ciò potrebbe accadere? Ho già eseguito questa procedura senza successo alcune volte, quindi sono un po 'sconcertato.

Aggiorna : in questo repository è presente ed è sempre stato il ramo principale. Solo per rispondere ad alcune delle risposte postate ...

Answer 1

Ho dato un'occhiata al repository in questione ed ecco cosa stava succedendo:

• Ad un certo punto, rpj aveva eseguito git checkout [commit id] . Ciò ha indicato HEAD a un impegno lento piuttosto che a un ramo riconosciuto. Credo che questa sia la "testa pendente" " problema a cui si riferisce CesarB.
• Non rendendosi conto di questo problema, ha continuato a modificarli e a commetterli, il che ha fatto esplodere HEAD ogni volta. Tuttavia, HEAD stava solo indicando una catena pendente di commit, non una filiale riconosciuta.
• Quando è andato a spingere i suoi cambiamenti, git ha spinto tutto in cima al maestro, che era solo circa a metà dell'albero attuale su cui si trovava.
• Segue confusione

Questo diagramma dovrebbe rendere più chiaro:

                 -- D -- E -- F
                /             ^
   A -- B -- C -              |
   ^         ^               HEAD
   |         |
 remote    master

Quando ha tentato di inviare le sue modifiche, sono state inviate solo da A a C e remote è passato a C . Non è stato in grado di eseguire il commit di D tramite F perché non vengano indicati da un ramo noto.

Ecco cosa vedi quando sei in questo stato:

$ git branch
* (no branch)
master

La soluzione è spostare master su F nella catena penzolante di commit. Ecco come l'ho fatto.

• Crea un ramo legittimo per lo stato corrente:

  git checkout -b tmp

  • Il ramo tmp ora punta a commit F nel diagramma sopra

• Avanzamento rapido master a tmp

  git checkout master

  git merge tmp

  • master ora punta su commit F .

• Butta via il tuo ramo temporaneo

  git branch -d tmp

• Puoi felicemente spingere nel repository remoto e dovrebbe inviare tutte le tue modifiche.

Answer 2

Da Git 1.7.3 in poi, puoi farlo con un semplice comando:

git checkout -B master

L'opzione -b significa & # 8220; crea qui un ramo prima di provarlo & # 8221; e -B è la versione incondizionata di questo, & # 8220; anche se il ramo esiste già & # 8211; in tal caso, spostalo qui prima di provarlo & # 8221 ;.

---

Un approccio molto semplice per risolvere questo tipo di problema è semplicemente eliminare il ramo master e ricrearlo. Dopotutto, i rami in git sono semplicemente nomi di commit e il ramo master non è niente di speciale.

Quindi supponendo che il commit corrente sia quello che vuoi sia master , lo fai semplicemente

git branch -D master

per eliminare il ramo master esistente, quindi

git checkout -b master

a a) crea un nuovo ramo chiamato master che punta al commit corrente eb) aggiorna HEAD per puntare al ramo master . Successivamente, HEAD verrà allegato a master e quindi master si sposterà in avanti ogni volta che commetti.

Answer 3

Controlla se stai spingendo i rami corretti e che i rami abbiano effettivamente quello che pensi abbiano. In particolare, controlla se non hai una HEAD staccata, che può essere abbastanza confusa se non fatta apposta.

Il modo più semplice per verificare è usare gitk --all , che mostra graficamente tutti i rami, HEAD e altro.

Answer 4

Suppongo che la prima cosa che farei sarebbe eseguire git fsck sul tuo repository locale per assicurarmi che sia tutto in ordine.

Non ho mai visto questo problema prima e non riesco a pensare a cosa potrebbe essere sbagliato.

Answer 5

Non ho la reputazione di commentare direttamente la risposta precedente di CesarB, ma gitk --all non funziona in questo caso perché elenca solo i rami noti.

gitk HEAD mostra questo problema, ma non è del tutto chiaro. La pistola fumante è che master mostra l'albero di commit anziché il commit più recente.

Answer 6

Quindi, risulta che entrambi: l'hash di commit in .git / refs / heads / master era corretto e le informazioni in .git / logs / refs / heads / master erano incomplete; nel senso che intendo solo è arrivato e incluso l'hash di commit specificato in .git / refs / heads / master.

Dopo aver riparato questi file (a mano) e rispedito a Github, tutto era di nuovo sugo. Non ho ancora nessuna idea cosa è successo per ottenere cose in questo stato, ma sono contento di aver almeno capito la soluzione.

Nel caso qualcuno si stia chiedendo: per correggere .git / refs / heads / master, ho appena sostituito il contenuto di quel file con l'ultimo hash di commit (HEAD) e per correggere .git / logs / refs / heads / master , Ho semplicemente copiato il contenuto di .git / logs / HEAD in .git / logs / refs / heads / master. Facile peasy ... NON.

Answer 7

Ho avuto questo stesso problema due volte, e finalmente ho capito che cosa stavo facendo che lo stava causando. Nel processo di modifica di un vecchio commit con git rebase -i , invece di chiamare git commit --amend , stavo chiamando git commit -a per forza dell'abitudine, immediatamente seguito da git rebase --continue , ovviamente. Qualcun altro potrebbe essere in grado di spiegare cosa sta succedendo dietro le quinte, ma sembra che il risultato sia il problema HEAD distaccato.