Domanda

Uso Tortoise SVN di solito, ma ho cercato Mercurial poiché è un sistema di controllo di revisione distribuito.

Quello che sto cercando, in entrambi i sistemi, è uno strumento che mi consente di selezionare solo parti di un file e di commetterle. Se voglio farlo ora, devo copiare in una versione temporanea del file e conservare solo le modifiche che voglio eseguire nella versione corrente, quindi copiare nuovamente la versione temporanea nella versione corrente dopo aver eseguito il commit. È solo una seccatura e il programma dovrebbe essere in grado di farlo per me.

Ho sentito che Git supporta questo, per favore fatemi sapere se questo è corretto.

È stato utile?

Soluzione

Mercurial può farlo con l'estensione record .

Ti verrà richiesto per ogni file e ogni pezzo diff. Ad esempio:

% hg record
diff --git a/prelim.tex b/prelim.tex
2 hunks, 4 lines changed
examine changes to 'prelim.tex'? [Ynsfdaq?]  
@@ -12,7 +12,7 @@
 \setmonofont[Scale=0.88]{Consolas}
 % missing from xunicode.sty
 \DeclareUTFcomposite[\UTFencname]{x00ED}{\'}{\i}
-\else
+\else foo
 \usepackage[pdftex]{graphicx}
 \fi

record this change to 'prelim.tex'? [Ynsfdaq?]  
@@ -1281,3 +1281,5 @@
 %% Local variables:
 %% mode: latex
 %% End:
+
+foo
\ No newline at end of file
record this change to 'prelim.tex'? [Ynsfdaq?]  n
Waiting for Emacs...

Dopo il commit, la differenza rimanente sarà lasciata indietro:

% hg di
diff --git a/prelim.tex b/prelim.tex
--- a/prelim.tex
+++ b/prelim.tex
@@ -1281,3 +1281,5 @@
 %% Local variables:
 %% mode: latex
 %% End:
+
+foo
\ No newline at end of file

In alternativa, potresti trovare più facile usare MQ (Mercurial Queues) per separare le singole modifiche nel tuo repository in patch. Esiste anche una variante MQ di record (qrecord).

Aggiornamento: prova anche l'estensione crecord , che fornisce un'interfaccia maledizioni alla selezione di hunk / line.

screenshot crecord

Altri suggerimenti

Sì, git ti consente di farlo. Il comando git add ha un'opzione -p (o --patch ) che ti permette di rivedere le tue modifiche pezzo per pezzo, seleziona quale mettere in scena (puoi anche perfezionare gli hunk o, modificare le patch in posizione). Puoi anche usare la modalità interattiva per git-add ( git add -i ) e usare " p " opzione.

Ecco un screencast sull'aggiunta interattiva che dimostra anche la funzione patch di git add .

Dai un'occhiata a TortoiseHG, che eseguirà la selezione di hunk e ti consentirà di eseguire diverse modifiche su un file per diversi commit.

Ti permetterà anche di eseguire il commit di tutte le modifiche ad alcuni file insieme a modifiche parziali ad altri file in un unico commit.

http://tortoisehg.bitbucket.io/

Ho chiesto a domanda simile poco tempo fa e la risposta risultante dall'uso di hgshelve extension era esattamente quello che stavo cercando.

Prima di eseguire un commit, puoi inserire le modifiche da diversi file (o parti di modifiche all'interno di un file) nello "scaffale" e poi commetti le cose che vuoi. Quindi puoi decodificare le modifiche che non hai eseguito e continuare a lavorare.

L'ho usato negli ultimi giorni e mi piace molto. Molto facile da visualizzare e utilizzare.

Mercurial ora fornisce un'opzione --interactive (o -i ) al comando commit , che abilita questa funzionalità fin dal di dialogo.

Funziona direttamente dalla riga di comando, quindi è perfetto se sei un appassionato di riga di comando!

Esecuzione

> hg commit -i

avvia una sessione interattiva che consente di esaminare, modificare e registrare singole modifiche per creare un commit.

Ciò si comporta in modo molto simile alle opzioni --patch e --interactive per git add e git commit comandi.

Consiglierei di non lavorare in questo modo.

Se devi impostare una serie di modifiche, imposta A che è pronto per il check-in e imposta B che non è ancora pronto, come puoi essere sicuro che solo il check-in nel set A non interromperà la tua build / test? Potresti perdere alcune righe, dimenticare le righe in un altro file o non realizzare una dipendenza che A ha su B che rompe la build per gli altri.

I tuoi commit dovrebbero essere discreti cambiamenti atomici che non rompono la build per te o altri nella tua squadra. Se stai parzialmente eseguendo il commit di un file, stai aumentando notevolmente le possibilità di infrangere la build per gli altri senza saperlo fino a quando non avrai un collega infelice che bussa alla tua porta.

La grande domanda è: perché senti il ??bisogno di lavorare in questo modo?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top