Sono un utente git confuso dalla ramificazione di mercurial. Come dovrei tenere traccia delle piccole modifiche?

Ho sempre usato Git prima, ma voglio contribuire a Python, quindi ora devo imparare Mercurial e lo trovo molto frustrante.

Quindi, ho creato un paio di piccole patch e volevo seguirle come commit nel mio repository mercurial locale. Apparentemente ci sono 4 modi per gestire la ramificazione in mercurial . 1 e 4 mi sembravano completamente ridicoli, i rami con nome sembrano essere dei pesi massimi e sento che non dovrei usarli per le correzioni rapide di 1 commit, quindi ho usato i segnalibri.

Ora, la mia patch viene rifiutata e voglio rimuovere uno dei miei rami dei segnalibri dal mio repository. OK, in git vorrei solo eliminare forzatamente il mio ramo e dimenticarmene, quindi cancello il mio segnalibro e ora ho i seguenti problemi:

• TortoiseHG e hg logmostra ancora che commit e defaultbranch hanno 2 teste. E se ho capito bene, non puoi cancellare i commit in hg senza plugin aggiuntivi.

• Mercurial non ha solo hash, ma anche numeri di revisione. Come ho aggiunto un paio di miei commit, tutti i commit estratti dopo che hanno numeri di revisione diversi dal repository centrale principale.

• Lo faccio hg updatedopo aver tirato per spostare automaticamente il mio mastersegnalibro sull'ultimo commit, ma non sono riuscito a trovare un modo per farlo in TortoiseHG.

Che cosa sto facendo di sbagliato? È normale e previsto e dovrei semplicemente ignorare questi problemi? O come dovrei lavorare con i miei rami?

Personalmente, per il tuo scenario, non mi preoccuperei nemmeno di creare un ramo, a meno che non stessi lavorando su più modifiche, ognuna delle quali avrebbe dovuto essere accettata dagli sviluppatori principali.

Basta clonare il loro repository e lavorarci sopra, quindi fare una richiesta pull.

Se dovessi usare un ramo, preferirei usare i rami con nome. Sono stati progettati per questo preciso scopo, dove i segnalibri non lo erano. Non vedo perché lo consideri pesante.

Mercurial ha un'intera pagina sulla sua wiki che descrive diversi modi di " Potatura di rami secchi ". L'opzione "Uso del clone" dovrebbe soddisfare le tue esigenze.

Per rispondere a problemi più specifici ...

TortoiseHG e hg log mostrano ancora che il ramo commit e predefinito ha 2 teste. E se ho capito bene, non puoi cancellare i commit in hg senza plugin aggiuntivi.

Questo è un errore che ho fatto con Mercurial quando ero nuovo. Non aver paura di quei plugin aggiuntivi. Alcuni di essi sono strumenti molto potenti e spesso vengono successivamente inseriti nel prodotto principale. Ecco come funziona Mercurial. Se ne hai bisogno per eseguire un'attività specifica, scaricala e usala.

La revisione della cronologia è considerata una brutta cosa nel mondo Mercurial, quindi il prodotto vanilla non ha sempre tutto ciò che un utente Git ritiene debba avere, ma ci sono molti plugin per coloro che vogliono usare l'applicazione ma hanno priorità diverse.

Mercurial non ha solo hash, ma anche numeri di revisione. Come ho aggiunto un paio di miei commit, tutti i commit estratti dopo che hanno numeri di revisione diversi dal repository centrale principale.

Non preoccuparti dei numeri di revisione. Sono una questione di convenienza, non di più. I codici hash sono gli identificatori importanti che passeranno da repo a repo. I numeri di revisione sono incoerenti tra i repository. Dai un'occhiata a Hg Init per una buona spiegazione.

I numeri di revisione sono solo una scorciatoia utile e più memorabile quando si lavora con un singolo repository.

Faccio l'aggiornamento hg dopo averlo tirato per spostare automaticamente il mio segnalibro principale sull'ultimo commit, ma non sono riuscito a trovare un modo per farlo in TortoiseHG.

Quando si utilizza TortoiseHG, utilizzare Workbench anziché gli altri strumenti. Tutto (quasi) è lì dentro. L'aggiornamento è nei menu di scelta rapida della revisione. Non è sempre intuitivo, ma c'è una buona guida al link sopra e man mano che ci si abitua, si finisce per fare clic con un abbandono sicuro.

Apparentemente ci sono 4 modi per gestire la ramificazione in mercurial. 1 e 4 mi sembravano completamente ridicoli, i rami con nome sembrano essere dei pesi massimi

In Mercurial, non crei filiali. Ogni commit è effettivamente una succursale, ogni commit può avere più genitori e più figli. Quindi questi sono i quattro modi diversi di organizzare le stesse entità.

È possibile dare loro nomi diversi, è non c'è bisogno di , ma è una buona idea. Non c'è niente di pesante nei rami con nome - sono solo alcuni metadati extra. Personalmente preferisco i rami con nome a qualsiasi altra cosa in qualsiasi situazione.

TortoiseHG e hg log mostrano ancora che il ramo commit e predefinito ha 2 teste.

Questo è esattamente il motivo per usare i rami con nome invece di scaricare tutto default.

E se ho capito bene, non puoi cancellare i commit in hg senza plugin aggiuntivi.

In realtà non puoi cancellare nulla in Mercurial e non dovresti . È possibile utilizzare hg stripma non è registrato: in pratica è sufficiente tagliare una parte del repository locale. Non puoi spingerlo, e se tiri da un repository che ha il ramo che hai rimosso localmente, ritorna.

Mercurial non ha solo hash, ma anche numeri di revisione. Come ho aggiunto un paio di miei commit, tutti i commit estratti dopo che hanno numeri di revisione diversi dal repository centrale principale.

I numeri non significano nulla. Puoi ignorarli se ti confondono.

Faccio l'aggiornamento hg dopo averlo tirato per spostare automaticamente il mio segnalibro principale sull'ultimo commit, ma non sono riuscito a trovare un modo per farlo in TortoiseHG.

Non ho usato TortoiseHG ma hg pull -ufarò entrambi pulle update.

Ho sempre usato Git prima, ma voglio contribuire a Python, quindi ora devo imparare Mercurial e lo trovo molto frustrante.

Va bene, molti utenti di Mercurial provano la stessa cosa per Git (incluso me).

Anche quando Mercurial e Git sono simili, hanno disegni diversi, forse la differenza progettuale più importante è che nel modificare Mercurial la storia non è flessibile come in git (perché è un po 'scoraggiato).

Risposta breve : non importa se hai una piccola quantità di modifiche, puoi comunque usare un ramo. Se stai pensando di eliminazione di quel ramo quindi utilizzare un segnalibro in modo da poter eliminare in un secondo momento e spogliare i cambiamenti in seguito.

Innanzitutto, provando a fare un po 'di luce su alcune delle cose che menzioni:

• 1 e 4 sono considerati diramazione perché ogni volta che si commette si crea effettivamente un ramo senza nome (se è presente un altro commit nello stesso momento nel repository di origine / benedetto), che tecnicamente è un ramo. Nel metodo 4 stai creando una nuova "testa" mentre nel metodo 1 non lo sei . Le teste dovrebbero essere unite. Sono d'accordo sul fatto che il metodo 1 sia un po 'sciocco, ma ad alcuni sembra piacere ... per piccoli progetti, immagino.

• Per quanto riguarda il metodo 2, non è che i rami siano pesanti, è che sono permanenti . Non è possibile rimuovere un ramo se non si utilizza qualcosa come l'estensione della striscia. Ancora una volta, la filosofia progettuale di Mercurial non mira a modificare la storia (ma è migliorata).

• Per quanto riguarda i numeri di revisione , sono solo un riferimento locale e più umanamente leggibile per l'uso di tutti i comandi che hanno a che fare con le revisioni. Se ti piace usare gli hash, puoi ancora farlo. I numeri di revisione sono solo una scorciatoia e vengono ignorati da Mercurial per qualsiasi operazione interna tra diversi repository.

Ora, per rispondere alle altre tue domande:

• Puoi controllare quali teste hai hg heads, se vedi 2+ teste in un singolo ramo con nome, è preferibile che siano unite. Questo è probabilmente dove si trova il tuo segnalibro .
• Per sbarazzarsi di una revisione che hai appena fatto, potresti farlo hg rollback, ma immagino che non sia così.
• Per eliminare un segnalibro basta farlo hg bookmark --delete yourbookmark
• Sarai felice che sia facile tagliare rami nella storia. Guardare nel prolungamento Rebase e l' operazione di Striscia .
• Mercurial è già fornito in bundle con diverse estensioni, ma non sono attivate per impostazione predefinita . Basta andare in qualsiasi cartella e fare clic con il tasto destro in qualsiasi punto per ottenere il menu di scelta rapida TortoiseHG, accedere a Impostazioni globali e quindi a Estensioni: attivare l'estensione MQ e l'estensione Rebase. Ciò non danneggia in alcun modo la compatibilità tra i repository.
• Ora che sei qui, puoi:
  • Spoglia dove è iniziato il tuo segnalibro (questo probabilmente risolve il tuo problema)
  • Per una visualizzazione più semplice, forse potresti modificare le modifiche nella parte anteriore e quindi rimuoverle in seguito. Ho appena menzionato rebase perché potrebbe essere qualcosa di utile per te un'altra volta.

Inoltre, in git puoi avere "filiali locali private" perché devi spingerle esplicitamente e puoi eliminarle in seguito. In Mercurial spingi tutto ciò che hai , tuttavia, se vuoi evitarlo , puoi utilizzare la funzione Fasi e contrassegnare una serie di revisioni come segrete . Le revisioni segrete non verranno spinte.

Infine, non stai facendo nulla di male , tieni presente che sono solo strumenti diversi costruiti con mentalità leggermente diverse, che praticamente si riducono a: modificare la storia (git) o ​​non modificare la storia (hg). In Mercurial è più difficile spararti nel piede modificando la storia (specialmente con le fasi) ed è per questo che ad alcuni piace meglio di Git .

Trovo che con mercurial sia più facile non preoccuparsi dei rami. Trovo da dove nella storia voglio modificare e creare commit come richiesto (ovvero rami anonimi). A volte i segnalibri potrebbero essere utili se devo saltare da una testa all'altra in contesti diversi, ma il più delle volte non mi preoccupo di loro. I rami nominati vanno bene per i rami di lunga durata (rami di correzione di bug, rami di progetto) ma per le correzioni di commit 1 o 2, non sono lo strumento giusto per il lavoro.

Il trucco con rami anonimi è di impostare la loro fase su "segreta" se non vuoi spingerli cioè se vuoi mantenerli locali. Se non vuole spingere, ma non ne voglio più commit basati su di essi, è appena commetti un "--close-ramo" sopra di loro il che significa che non sono più visualizzati nell'elenco 'teste' e mercuriale smetterò di lamentarmi di più teste su quel ramo.

Penso che possiamo semplicemente usare il segnalibro invece del ramo; continueremo comunque a supportare il prodotto e la fusione di due filiali a lungo termine sarebbe un grosso mal di testa.