Come impedire a Magit di chiedere dove spingere un ramo?

Quando chiamo magit-push-currentcon P Pdal buffer di stato, Magit 2.1.0mi chiede dove spingere il ramo la prima volta, quando non è impostato upstream.

Come può consentire di generare automaticamente il nome come prima?

magit

— z1naOK9nu8iY5A
fonte

Nel caso non lo sapessi, il nome generato automaticamente è una delle opzioni di completamento. Quindi, la prima volta che passi some-branch-nameal origintelecomando, probabilmente puoi semplicemente digitare o TAB s TABe otterrai il nome che desideri.

— Malabarba,

Oh ok non lo sapevo, grazie. Il problema è che ho molti rami che iniziano con gli stessi prefissi, il che non è molto utile, inoltre ho sempre messo rami remoti con lo stesso nome dei rami locali.

— z1naOK9nu8iY5A

Risposte:

Aggiornamento: il "ramo push" menzionato di seguito è stato implementato ormai. Vedere la documentazione sulla ramificazione per ulteriori informazioni.

Devi impostare il ramo upstream una volta. Una volta fatto ciò, si P Pspinge a quello e si otterranno elenchi di modifiche non annullate e non eliminate nel buffer di stato (a condizione che ce ne siano).

Esistono vari modi per impostare il ramo a monte. È possibile utilizzare il --set-upstreampassaggio dalla comparsa push: P -u P. Oppure utilizzare il comando che imposta il monte e non fa altro: b u.

Inoltre, Magit ora imposta automaticamente il ramo a monte durante la creazione di un nuovo ramo, a condizione che il "punto di partenza" sia il nome di un ramo. Questo funziona per "upstream" locali e remoti. Ma nota che se scegli un ramo locale come punto di partenza, questo non ti aiuterà a spingere. Il passaggio dal repository corrente al repository corrente ovviamente non ha senso ed è vietato.

Pertanto, quando il ramo "upstream" è in realtà un altro ramo locale, si P Pcomporta come se non fosse configurato alcun ramo upstream e si comporta esattamente come P e. Lo stesso è il caso se nessun upstream è configurato affatto.

Ciò a causa di una limitazione in Git: si può associare solo un altro ramo con qualche ramo, e quel ramo viene quindi chiamato "ramo a monte". Sarebbe meglio se esistessero almeno una filiale "a monte" e una "pubblicazione". Alla fine ho intenzione di implementarlo in Magit. Vedi numero 1485 .

Quindi, se si desidera essere in grado di spingere proprio in P Pquel momento, il ramo "upstream" deve essere ad es. "Origin / master", non "master".

Sto pensando di aggiungere una variante push che funziona sempre git pushsenza alcun argomento. Ciò che farebbe quindi dipenderebbe esclusivamente dalla configurazione di Git.

— tarsius
fonte

Mi sono ramificato da mastere non si è impostato a monte, dovrei forse diramare origin/masterper impostare automaticamente l'upstream?

— z1naOK9nu8iY5A

Vedi la risposta aggiornata.

— Tarsius,

Diramazione da origin/masterset origin/mastercome a monte, ma mi sarei aspettato di avere origin/branch-namea monte.

— z1naOK9nu8iY5A

Se è quello che vuoi, allora è meglio farlo durante la spinta. P -p P <... completion ...> RETSi noti che origin/branch-nameviene offerto come candidato per il completamento, quindi non è necessario digitarlo.

— Tarsius,

Questo è doloroso quando si utilizza gitflow e si estraggono richieste di revisione del codice, con un ramo per funzione, perché in genere si esegue il push una sola volta ed è sempre quello di creare un ramo remoto con lo stesso nome del ramo locale. Spingere in un altro ramo con nome sarebbe una fine corsa attorno alla revisione del codice.

— Barry Kelly,

Uso i seguenti consigli che si attivano automaticamente --set-upstreamquando il ramo corrente non ha ancora un upstream:

(defun magit-push-arguments-maybe-upstream (magit-push-popup-fun &rest args)
  "Enable --set-upstream switch if there isn't a current upstream."
  (let ((magit-push-arguments
         (if (magit-get-remote) magit-push-arguments
           (cons "--set-upstream" magit-push-arguments))))
    (apply magit-push-popup-fun args)))
(advice-add 'magit-push-popup :around #'magit-push-arguments-maybe-upstream)

In combinazione con il completamento ido questo consente di spingere un nuovo ramo con P P RET:

;; NOTE: requires ido-completing-read+
(setq magit-completing-read-function #'magit-ido-completing-read)

— npostavs
fonte

Questo è veramente forte! Grazie mille!

— z1naOK9nu8iY5A

Creo semplicemente il nuovo ramo con b ce poi modifico il .git/configfile in modo che punti origin/branchpiuttosto che fare il monkeying con tutta la roba di magit 2, che comunque non sembra funzionare.

Modificare:

[branch "fix_something"]
  remote = .
  merge = refs/heads/master

Per

[branch "fix_something"]
  remote = origin
  merge = refs/heads/fix_something

Funziona, mentre in magit2 non ho ancora trovato una combinazione chiave che compia la stessa cosa. Cercare di impostare il telecomando non funziona perché non esiste ancora sull'origine.

— David N. Welton
fonte

L'upstream può essere impostato utilizzando bu. Ma questo usa git branch --set-upstream-toe come sai Git non può impostare un ramo inesistente come upstream e quindi nemmeno Magit.

— tarsius,

@tarsius magit 1 sembrava fare ciò di cui avevo bisogno. Sto solo cercando di recuperare qualche parvenza di quel flusso di lavoro.

— David N. Welton,