2009-11-12 15 views
85

Ho una coppia di commit che dovrebbe essere solo uno. Se stavo usando git, vorrei usare:Posso schiacciare commit in Mercurial?

git rebase -i <some-commit-before> 

e poi schiacciarli.

Posso farlo in mercurial? Se é cosi, come?

+0

@ Ry4an: Grazie, non l'ho notato (diversa scelta di parole). –

+0

Sì, mi ci è voluto un po 'per trovarlo perché la tua domanda era più chiara. –

risposta

80

Sì, è possibile farlo utilizzando mercurial senza alcuna estensione da Concatenating Changesets.

In alternativa, se si desidera utilizzare un'estensione si potrebbe usare:

+0

Sì, ho pescato quella risposta tra le doppie domande che mi piacevano nel mio commento sulla domanda generale. Penso che sia la tua risposta su quello. –

+0

Collapse extension era facile da installare e molto facile da usare, esattamente quello che stavo cercando! – MattGWagner

+3

Una piccola nota a margine: l'estensione Histedit è distribuita con Mercurial 2.3 e versioni successive. Devi solo abilitarlo. – Paidhi

35

il mio preferito è hg strip --keep comando. E poi commetto tutte le modifiche in un commit.

E 'il modo più veloce e più comodo per me, perché mi piace fare tante piccole commit durante il mio lavoro quotidiano;)


Nota 1: strip ha bisogno di un'estensione integrata mq da abilitare .
Nota 2: Il mio client Git/Mercurial preferito (SmartGit/Hg) aggiunge il parametro --keep per impostazione predefinita durante strip. E ciò che è ancora più conveniente: fornisce l'opzione denominata join commits:]

+4

Il comando completo per hg strip è: 'hg strip --keep --rev [rev]' Dove 'rev' è il numero di revisione del primo commit che vuoi schiacciare con l'ultimo –

+3

@NicolasForney Non esattamente,' --rev' è opzionale, il comando completo è 'hg strip --keep [rev]' –

+0

La revisione è obbligatoria per me in 3.3.3: 'hg help strip' dà' hg strip [-k] [-f] [-n] [-B segnalibro] [-r] REV ... ', e omettendo la revisione mi dà' abort: empty revision set'. –

21

Il Rebase extension ha funzionato come un fascino. Per schiacciare 2 commit:

$ hg rebase --dest .~2 --base . --collapse 

Dot è una scorciatoia per la revisione in corso.

E 'ancora più facile quando si dispone di un paio di commit su un ramo e si vuole a tutti loro collassare in uno:

$ hg rebase --dest {destination branch (e.g. master)} --base . --collapse 

Come funziona:

enter image description here

(da http://mercurial-scm.org/wiki/RebaseExtension#Collapsing)

+0

questo è perfetto! – phouse512

+0

Dove hai trovato il "~ 2" per due commit? –

+0

È spiegato nell'argomento revsets, vedere hg help revsets. – markand

5

Se stai leggendo questa risposta, puoi dimenticare ogni altro opt ion menzionato in questa risposta e utilizzare il comando fold dal evolve extension.

evolve è un'estensione di mercurial che ci aiuta ad avere una cronologia mutabile sicura, tuttavia è ancora sperimentale. Puoi usarlo clonandolo dal suo repo e aggiungendolo nel tuo .hgrc in questo modo.

[extensions] 
evolve = ~/evolve/hgext/evolve.py 

Supponendo di aver clonato il repository evolve nella home directory. Ora sei a posto. Puoi anche cercare aiuto per hg help fold.

Fold Command

vi dica fold di zucca/piegare una catena lineare di commit che non è rotto. Ciò che piega è, crea un nuovo changeset che contiene le modifiche da tutti i changeset e contrassegna tutti quei commit come obsoleti. Puoi avere una visione più approfondita di questo a docs.

Ora supponiamo di avere la seguente cronologia.

a -> b -> c -> d -> e -> f -> g 

Si desidera schiacciare e, f e g. Si può fare

hg up g 
hg fold -r e 

Il risultato sarà

a -> b -> c -> d -> h 

dove h è l'insieme di modifiche che contiene le seguenti variazioni tutti e tre i commit e, f e g.

Puoi anche piegare i changeset dal centro della cronologia, cioè non necessariamente devi scegliere una catena che include la punta. Supponiamo di voler piegare b, c e d. Si può fare

hg up d 
hg fold -r b 
hg evolve --all 

questo si tradurrà in

a -> i -> j 

dove i è l'insieme di modifiche piegato di b, c, d e j è lo stesso changeset come h. Evolve user guide è una lettura obbligata.

+0

Sembra che le copertine di rebase utilizzino i casi (forse tutti?) Di questa estensione, e sicuramente quella che viene posta in questa domanda. La caratteristica killer di quell'estensione è quella di nascondere (piuttosto che eliminare) le revisioni che si sostituiscono, ma l'opzione '--keep' di rebase copre questo (seguito dalla marcatura delle revisioni come segrete, o usando la striscia su di esse una volta controllato risultato). È anche possibile spostare le revisioni tra altre revisioni con una sequenza di due comandi rebase. –

+0

... inoltre, se stai facendo qualcosa di veramente complicato, puoi sempre clonare il repository locale prima di usarlo come backup. Considerando quanto sia raro (si spera!), È meno sforzo che imparare a usare un'estensione totalmente nuova. –

Problemi correlati