Qual è l'approccio Git per pubblicare una coda di patch?

20

Sono abituato a Mercurial mq extension per mantenere un set di patch personalizzate sull'upstream. Possono essere pubblicati come repository separati oltre al monte. Ora in git uso le filiali private e rebase, e funziona bene fino a quando non voglio condividere le mie patch con qualcun altro.Qual è l'approccio Git per pubblicare una coda di patch?

In Mercurial la coda patch è un repository indipendente e può essere pubblicata come al solito. Bitbucket offre anche una funzionalità di coda di patch per collegarla al repository principale. In Git, se pubblico un ramo privato con le mie patch, perdo la possibilità di rebase di loro più (a meno che non interrompa le unioni), tuttavia le patch devono essere aggiornate di volta in volta.

Da another SO question Ho trovato che nel mondo Git StGit viene proposto come equivalente per mq. È simile in uso a mq, ma come faccio a pubblicare una coda di patch con StGit?

(stg publish sembra essere indended per creare un solo un nuovo “merge friendly” ramo, di non pubblicare le patch stessi)

Quali sono altri approcci per pubblicare le code di patch in Git?

fonte

2011-02-16 sastanin

+6

C'è qualche ragione per cui non puoi semplicemente pubblicare il ramo con la consapevolezza che non è finalizzato e può essere ulteriormente ridefinito? – Cascabel

+0

Beh, interromperà le fusioni per chiunque tenti di estrarre/recuperare da esso, giusto? Allora che senso ha pubblicarlo come repo controllato dalla versione, se non consente di aggiornare senza problemi l'ultima versione? – sastanin

+2

@jetxee: Questo è il punto: se può essere ulteriormente ribadito, * non * lo unisci in rami importanti. Si recupera e si lavora su di esso in isolamento. – Cascabel

7

Per riassumere le risposte e i commenti. Con git ci sono due approcci per pubblicare piccole modifiche personalizzate per il telecomando a monte:

dimenticano rebase, pubblicare un ramo e nuove unioni, se necessario
dichiarare che un ramo è ribasamento, solo rebase e pubblicare (pro: storia pulita, contra: può essere un dolore per essere utilizzato in modo continuo da qualcun altro, ad esempio: linux-next)

Finora il flusso di lavoro coda delle patch pura non sembra essere fattibile con git, ma sembra guilt essere molto vicino a mq, anche nam es dei comandi. Non consente una coda di patch controllata dalla versione (e pubblicabile).

fonte

2011-02-21 10:18:16 sastanin

-1

AFAICT dal collegamento fornito su Mq, ha gli stessi problemi di pubblicazione di git rebase?

Tutto sommato credo che pubblicare il proprio ramo, con l'avvertimento che si tratta di un ramo di ribasso è la soluzione migliore. Ad esempio, è così che viene mantenuto il ramo linux-next.

fonte

2011-02-19 20:40:23 Rawler

+1

Consente di inserire le patch sotto il controllo della versione in un repository _separato, pertanto il repository principale non viene modificato e il repository con le patch può essere pubblicato indipendentemente da solo. Quindi non ha gli stessi problemi di 'git rebase', perché non riscrive la cronologia (in effetti, non la modifica affatto). – sastanin

+0

@jetxee, ok quindi è un modo per annotare il ramo "unstable", avvertendo che è instabile e ribasato? Sembra una buona cosa avere. – Rawler

+1

è un modo per gestire un set di patch che non sono ancora state assegnate alla linea principale; è possibile applicare rapidamente (qpush) e unpply (qpop), riordinarli e modificarli. Le patch stesse sono gestite come semplici file. Quando vengono applicati, l'intera coda di patch assomiglia a un ramo per il mercurial, quando non vengono applicati il repository appare come se non esistessero. È opportuno mantenere le personalizzazioni private, sviluppare funzionalità complesse (come con rebase) o sperimentare. StGit e Guilt sembrano fare lo stesso per Git. – sastanin

1

Considerando i commenti forniti, sembra che un approccio più o meno equivalente ai mq di Mercurial sarebbe quello di usare la colpa. A differenza di mq, il senso di colpa non fornisce direttamente un'interfaccia per un "repository di patch", ma è possibile trasformare manualmente lo .git/patches/<branch> in un repository .git.

fonte

2011-03-09 21:13:01

0

C'è un'estensione git chiamata git-series che utilizza git per mantenere una coda di patch con versione. Consente funzionalità simili a mq in quanto è possibile gestire più serie (equivalenti a più code hg), patch di refact in base al feedback e impegnare la serie su git. È il più vicino a mq, ma è abbastanza diverso da aspettarsi qualche tiro al piede.

fonte

2017-10-11 20:10:25 ctuffli

Qual è l'approccio Git per pubblicare una coda di patch?

risposta

Problemi correlati