Perché non posso spingere in questo repository nudo?

283

Puoi spiegare cosa c'è di sbagliato in questo flusso di lavoro?

$ git init --bare bare
Initialized empty Git repository in /work/fun/git_experiments/bare/
$ git clone bare alice
Cloning into alice...
done.
warning: You appear to have cloned an empty repository.
$ cd alice/
$ touch a
$ git add a
$ git commit -m "Added a"
[master (root-commit) 70d52d4] Added a
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a
$ git push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to '/work/fun/git_experiments/bare'

Non git pushspinge sempre nel repository da cui ho clonato?

git

— ripper234
fonte

Non dovresti specificare il ramo da spingere?

— Rekin,

3

non dopo un clone !!! dopo che il problema è stato risolto, funziona benissimo e non è necessario specificare il ramo ... solo su questo primo checkout di un repository vuoto si verifica ciò che è MOLTO MOLTO fastidioso ... dovrebbero risolvere questo problema.

— Dean Hiller,

Spero che questo post sia utile a qualcuno quando provi a fare sopra- samranga.blogspot.com/2015/07/… L'errore nella domanda può essere spuntato anche quando si tenta di creare un repository BitBucket git da un progetto già localmente

— Samitha Chathuranga,

483

Sì, il problema è che non ci sono commit in "nudo". Questo è un problema solo con il primo commit, se si creano i repository nell'ordine (bare, alice). Prova a fare:

git push --set-upstream origin master

Ciò sarebbe richiesto solo la prima volta. Successivamente dovrebbe funzionare normalmente.

Come ha sottolineato Chris Johnsen, non avresti questo problema se il tuo push.default fosse personalizzato. Mi piace upstream / tracking.

— Seth Robertson
fonte

1

Lo sto facendo sudo apt-get upgrade git-coree sudo apt-get upgrade gitpenso che non sia necessario alcun aggiornamento. git --versionrestituisce 1.7.3.1. Qualche idea di cosa manca? Ammetto che attualmente apt-get updatenon funziona per me, ma non è passato molto tempo fa.

— ripper234,

1

@ ripper234: la versione corrente di git è 1.7.5.3 Puoi vivere con l'inconveniente, usare un flusso di lavoro diverso o installare manualmente l'ultimo git senza pacchetto debian / ubuntu.

— Seth Robertson,

Ah giusto, dimentico che il software impiega un po 'di tempo prima che venga impacchettato. Sono un noob di Linux, proveniente da Windows e usato per fare clic qui per installare la versione più recente.

— ripper234,

9

Per quanto riguarda "La versione recente non presenta questo problema": Anche nelle versioni recenti, l'impostazione predefinita per i push non sembra essere cambiata da matching; forse hai push.defaultimpostato su upstream/ tracking(o current) nel tuo ~/.gitconfig?

— Chris Johnsen,

4

Prova git push origin master:mastera renderlo esplicito. Se il problema persiste, controlla per quale ramo sei: git branchforse non hai effettuato il primo commit o lo hai fatto su un ramo diverso dal master.

— Seth Robertson,

43

Se tu:

 git push origin master

spingerà al repository nudo.

Sembra che il tuo repository Alice non stia monitorando correttamente.

cat .git/config

Questo mostrerà il telecomando e il ramo predefiniti.

Se tu

 git push -u origin master

Dovresti iniziare a tracciare quel telecomando e quel ramo. Non sono sicuro che questa opzione sia sempre stata in git.

— serby
fonte

30

La risposta di questa domanda correlata mi ha fornito la soluzione ... è stato solo un errore stupido:

Ricordati di impegnarti per primo!

https://stackoverflow.com/a/7572252

Se non ti sei ancora impegnato nel tuo repository locale, non c'è nulla da spingere, ma il messaggio di errore Git che ricevi non ti aiuta molto.

— phpguru
fonte

17

git push --all

è il modo canonico di spingere tutto in un nuovo repository nudo.

Un altro modo per fare la stessa cosa è creare il tuo nuovo repository non bare e quindi creare un clone nudo

git clone --bare

quindi utilizzare

git remote add origin <new-remote-repo>

nel repository originale (non nudo).

— Ebneter
fonte

... quindi hai ridimensionato la risposta? Si è il modo standard per spingere tutto per un nuovo repository nudo. Se non ha funzionato per te, c'è qualche altro problema.

— ebneter,

Hai ragione, probabilmente non avrei dovuto, so che stavi solo cercando di aiutarti. Se lo modifichi annullerò il mio downvote.

— ripper234,

Grazie, modificato con un altro modo per svolgere la stessa attività.

— ebneter,

La tua risposta mi ha aiutato grazie;) Ma alla fine del comando, il percorso deve essere presente in questo modo: git push --all ../test_repol'URL del repository alla fine del comando;)

— Metafaniel,

@Metafaniel Dipende da come lo hai impostato. Se il tuo repository locale ha già il telecomando configurato correttamente, "git push --all" dovrebbe funzionare così com'è.

— ebneter,

7

Prova questo nel tuo alicerepository (prima di spingere):

git config push.default tracking

Oppure, configuralo come predefinito per il tuo utente con git config --global ….

git pushfa per impostazione predefinita il originrepository (che normalmente è il repository da cui è stato clonato il repository corrente), ma per impostazione predefinita non esegue il push del ramo corrente, ma per impostazione predefinita spinge solo i rami esistenti sia nel repository di origine che nel repository di destinazione.

La push.defaultvariabile di configurazione (vedi git-config (1) ) controlla cosa git pushspingerà quando non viene dato alcun argomento "refspec" (cioè qualcosa dopo un nome di repository). Il valore predefinito indica il comportamento sopra descritto.

Ecco i possibili valori per push.default:

nothing
Questo ti costringe a fornire un "refspec".
matching(impostazione predefinita)
Spinge tutti i rami esistenti sia nel repository di origine che nel repository di destinazione.
Questo è completamente indipendente dal ramo che è attualmente estratto.
upstreamoppure tracking
(Entrambi i valori significano la stessa cosa. Il successivo è stato deprecato per evitare confusione con i rami di "monitoraggio remoto". Il primo è stato introdotto in 1.7.4.2, quindi dovrai usare il secondo se stai usando Git 1.7.3.1. )
Questi spingono il ramo corrente nel ramo specificato dalla sua configurazione "a monte".
current
In questo modo il ramo corrente viene spostato sul ramo con lo stesso nome nel repository di destinazione.

Questi ultimi due finiscono per essere gli stessi per i casi comuni (ad esempio lavorando su master locale che utilizza origin / master come upstream), ma sono diversi quando il ramo locale ha un nome diverso dal suo ramo “upstream”:
```
git checkout master
# hack, commit, hack, commit

# bug report comes in, we want a fix on master without the above commits

git checkout -b quickfix origin/master  # "upstream" is master on origin
# fix, commit
git push
```
Con push.defaultuguale upstream(o tracking), la spinta sarebbe andato a origin's maestro ramo. Quando è uguale a current, la spinta sarebbe andare a origin's quickfix ramo.

L' matchingimpostazione aggiornerà bareil master nel tuo scenario una volta stabilito. Per stabilirlo, è possibile utilizzare git push origin masteruna volta.

Tuttavia, l' upstreamimpostazione (o forse current) sembra che potrebbe corrispondere meglio a ciò che ti aspetti, quindi potresti provare:

# try it once (in Git 1.7.2 and later)
git -c push.default=upstream push

# configure it for only this repository
git config push.default upstream

# configure it for all repositories that do not override it themselves
git config --global push.default upstream

(Ancora una volta, se stai ancora usando un Git prima dell'1.7.4.2, dovrai usare trackinginvece di upstream).

— Chris Johnsen
fonte

1

Uso il client git di SourceTree e vedo che il loro comando di commit / push iniziale è:

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags --set-upstream origin master:master

— IgorGanapolsky
fonte