Contrassegna le modifiche come già unite o deliberatamente ignorate con hg pull/push/merge/graft?

Question

Sto transizione a Mercurial da Subversion, dove mi sono abituato ad usare svnmerge.py tenere traccia delle modifiche che sono già state fuse, o che sono state bloccate da essere fuse:

# Mark change 123 as having already been merged; it will not be merged again, even if a range 
# that contains it is subsequently specified. 
svnmerge.py merge -M -r123 
# 
# Block change 326 from being considered for merges. 
svnmerge.py merge -X -r326 
# 
# Show changes that are available for merging from the source branch. 
svnmerge.py avail 
# 
# Do a catchall merge of the remaining changes. Neither change 123 nor change 326 will be 
# considered for merging. 
svnmerge.py merge 

voglio essere in grado di fare qualcosa di simile per hg pull/push/merge/graft, in modo che se so che non voglio mai unire una determinata modifica, posso semplicemente bloccarlo dalla considerazione, rendendo successivamente il cherry-picking, l'unione, ecc. un affare più ignaro. Ho fatto molte ricerche su google, ma non ho trovato il modo di farlo.

Sembra inoltre che non ci sia modo di visualizzare un elenco di modifiche non ancora disegnate.

Dato che sto spesso riordinando gli altri sviluppatori e aiutandoli con le loro unioni, è estremamente utile essere in grado di fare questo genere di cose, che si potrebbe considerare "inverso cherry-picking"; Ad esempio, contrassegnare le modifiche che NON si desidera unire e quindi eseguire un'unione di massa del resto.

Answer 1

I sistemi basati su DAG come Mercurial ans Git sono tutto o niente: quando si uniscono due rami, si esegue un'unione a tre vie dell'antenato comune e dei due rami.

L'unione a tre vie è solo riguarda la fase finale di ogni ramo. Ad esempio, non importa se si apportano le modifiche in 10 e 1000 passaggi: il risultato della fusione sarà lo stesso.

Ciò implica che l'unico modo per ignorare un changeset è una copia di fuori prima della fusione:

$ hg backout BAD 

che annullerà l'insieme di modifiche sul ramo, facendo apparire che non è mai stato fatto dal punto di vista della fusione a tre.

Se si dispone di un intero ramo che si desidera unire, ma ignora, allora si può fare una fusione manichino:

$ hg merge --tool internal:local --non-interactive 
$ hg revert --all --rev . 

che attraversa l'unione, ma ritorna al vecchio stato prima commettere.

---

Il miglior consiglio che posso darti è di strutturare il flusso di lavoro in modo che i suddetti backout non siano necessari. Ciò significa eseguire un bugfix sul ramo applicativo più vecchio . Se viene rilevato un errore durante la creazione della funzione X, utilizzare hg bisect per capire quando è stato introdotto il bug.Ora aggiornata nel ramo più antico in cui si vuole ancora di risolvere il bug:

$ hg update 2.0 
# fix bug 
$ hg commit -m "Fixed issue-123" 

poi unire i bugfix in tutti i rami successivi:

$ hg update 2.1 
$ hg merge 2.0 
$ hg commit -m "Merge with 2.0 to get bugfix for issue-123" 

$ hg update 2.2 
$ hg merge 2.1 
$ hg commit -m "Merge with 2.1 to get bugfix for issue-123" 

Se il bugfix non si applica più, allora si dovrebbe ancora fondersi, ma buttare via i cambiamenti non correlati:

$ hg update 3.0 
$ hg merge 2.2 --tool internal:local --non-interactive 
$ hg revert --all --rev . 
$ hg commit -m "Dummy merge with 2.2" 

che assicura che si può sempre utilizzare

$ hg log -r "::2.2 - ::3.0" 

per visualizzare i changeset sul ramo 2.2 che non sono stati ancora uniti in 3.0.