Il cherry-pick richiama semplicemente le modifiche nell'albero di lavoro corrente come modifiche non vincolanti?

1. Cherry-pick per Mercurial è hg graft
2. La cronologia dei commit innestati è facilmente recuperabile, specialmente se l'innesto viene eseguito con --log option e senza --edit + messaggio di commit di modifica di madcap. Anche la buona GUI (TortoiseHG) rivela la storia dell'innesto.

Toy-repo con alcuni innesti (release + devel branching model)

Glog ouput in console:

hg glog --style changelog
2015-08-05  Author <email>

@       * c.txt, cd.txt:
|       Cnange 4
|       [769d5ba1b198] [tip] <release>
|
o       * c.txt:
|       Cnange 3 (grafted from 3044bbf6fe3542b86d0a1a84b7455d76928b559b)
|       [e58f524b1203] <release>
|
o       * a.txt:
|       Cnange 1
|       [23d4aaf0c632] <release>
|
o       * Release branch created
|       [9f39dda2e0d9] <release>
|
| o     * c.txt, cd.txt:
| |     Cnange 4
| |     [c5523fade515]
| |
| o     * b.txt:
| |     Edit 2
| |     [7efeb998f47e]
| |
| o     * a.txt:
| |     Edit 1
| |     [4f2e0bffed8a]
| |
| o     * c.txt:
| |     Cnange 3
| |     [3044bbf6fe35]
| |
| o     * b.txt:
| |     Cnange 2
| |     [278066927656]
| |
| o     * a.txt:
|/      Cnange 1
|       [e233699bf798]
|
o       * .hgignore:
        Initial structure
        [3bf949e66c66]

(changeset innestati 1,3,6 Solo il changeset 3 è stato innestato con --log aggiunto. Nota messaggio di commit invariato per 1 e 6)

e questo repository dopo tutto l'innesto in TortoiseHG

Non sono sicuro di mercurial, ma git cherry-pick creerà un nuovo commit per contenere le modifiche a meno che non lo dici diversamente. Il punto cruciale è che stacca il commit dalla sua cronologia, incluso qualsiasi commit da cui dipende per il corretto funzionamento. Ciò lo rende anche un problema quando devi unire testing di modifiche nel ramo di sviluppo e rende difficile o impossibile utilizzare gli strumenti di controllo di versione incorporati per fare praticamente qualsiasi paragone che vorresti fare tra testing e develop , comprese domande semplici come "La correzione di bug è stata apportata a testing ?"

Vorrei scoprire le ragioni per cui la ramificazione non è un'opzione. Forse lo stanno basando su una precedente esperienza di fusione negativa in un sistema di controllo della versione subpar (praticamente tutti erano cattivi alla fusione prima che hg e git arrivassero, e molti ancora sono cattivi).

Venderei rami di funzionalità in grado di selezionare commit con funzioni completate insieme a tutte le dipendenze richieste, mantenendo sempre la possibilità di tracciare e confrontare tra development e testing . cherry-pick è utile per correggere la circostanza eccezionale occasionale che il tuo modello di ramificazione non ha tenuto conto, ma usarlo come base totale per la gestione della configurazione è un problema.