Sono un utente git confuso dalla ramificazione di Mercurial. Come faccio a tenere traccia dei piccoli cambiamenti?

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

Basta clonare il loro repository e lavorarci, quindi effettuare una richiesta di pull.

Se dovessi usare un ramo, preferirei usare i rami nominati. Sono stati progettati per questo scopo esatto, 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 " Potare i rami morti ". L'opzione "Usare clone" dovrebbe soddisfare i tuoi requisiti.

Per rispondere ai tuoi problemi più specifici ...

TortoiseHG and hg log still show that commit and default branch has 2 heads. And if I understand correctly, you can't delete commits in hg without additional plugins.

Questo è un errore che ho fatto con Mercurial quando ne ero nuovo. Non aver paura di questi plugin aggiuntivi. Alcuni di questi sono strumenti molto potenti e spesso in seguito vengono inseriti nel prodotto principale. È così che funziona Mercurial. Se ne hai bisogno per eseguire un'attività specifica, prendila 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 pensa che dovrebbe avere, ma ci sono molti plugin per coloro che vogliono usare l'applicazione ma hanno priorità diverse.

Mercurial has not only hashes, but also revision numbers. As I've added a couple of my own commits, all commits pulled after that have different revision numbers from the main central repo.

Non preoccuparti dei numeri di revisione. Sono una questione di convenienza, non di più. I codici hash sono gli identificatori importanti che passeranno dal repo al repo. I numeri di revisione non sono coerenti tra i repository. Consulta Hg Init per una buona spiegazione.

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

I do hg update after pulling to move my master bookmark to the latest commit automatically, but I couldn't find a way to do that in TortoiseHG.

Quando usi TortoiseHG, usa Workbench piuttosto che gli altri strumenti. Tutto (quasi) è lì dentro. L'aggiornamento è nei menu di contesto della revisione. Non è sempre intuitivo, ma c'è una buona guida al link qui sopra e, appena ci si abitua, si finisce per fare clic con abbandono sicuro.

Apparently there are 4 ways to handle branching in mercurial. 1 and 4 looked completely ridiculous to me, named branches seem to be heavyweight

In Mercurial, non crea rami. Ogni commit è effettivamente un ramo, ogni commit può avere più genitori e più figli. Quindi questi sono i quattro diversi modi per organizzare le stesse entità.

puoi dargli nomi diversi, non devi , ma è una buona idea. Non c'è nulla di pesante nei rami con nome: sono solo alcuni metadati extra. Personalmente preferisco i rami nominati a qualsiasi altra cosa in qualsiasi situazione.

TortoiseHG and hg log still show that commit and default branch has 2 heads.

Quale è esattamente la ragione per utilizzare i rami nominati invece di riversare tutto in default .

And if I understand correctly, you can't delete commits in hg without additional plugins.

In realtà non puoi cancellare qualcosa in Mercurial e non dovresti . Puoi usare hg strip ma non è registrato - basicamente basta tagliare una parte del repository locale. Non puoi spingerlo, e se tiri da un repository che ha il ramo che hai spogliato localmente, torna indietro.

Mercurial has not only hashes, but also revision numbers. As I've added a couple of my own commits, all commits pulled after that have different revision numbers from the main central repo.

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

I do hg update after pulling to move my master bookmark to the latest commit automatically, but I couldn't find a way to do that in TortoiseHG.

Non ho usato TortoiseHG ma hg pull -u farà sia pull che update .

I've always used git before, but I want to contribute to python so now I have to learn mercurial and I find it very frustrating.

Va bene, molti utenti Mercurial si sentono uguali su Git (incluso me).

Anche quando Mercurial e Git sono simili, hanno design differenti, forse la differenza di design più importante è che in Mercurial la modifica della cronologia non è flessibile come in git (perché è un po 'scoraggiato).

Risposta breve : non importa se hai una piccola quantità di modifiche, puoi comunque utilizzare un ramo. Se stai pensando di eliminare quel ramo, utilizza un segnalibro in modo da poterlo eliminare in un secondo momento e rimuovere le modifiche successivamente.

Per prima cosa, cerca di fare un po 'di luce su alcune delle cose che hai menzionato:

• 1 e 4 sono considerati branching perché ogni volta che esegui il commit, crei in modo efficace un ramo senza nome (se c'è un altro commit allo stesso tempo nel repository source / benedetto), che tecnicamente è un ramo. Nel metodo 4 stai creando una nuova "testa" mentre nel metodo 1 non sei . I capi dovrebbero essere uniti. Sono d'accordo sul fatto che il metodo 1 sia piuttosto stupido, ma a qualcuno sembra piacere ... per i piccoli progetti, direi.

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

• Per quanto riguarda i numeri di revisione , sono solo un riferimento locale e più leggibile affinché tu possa utilizzare 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 sono ignorati da Mercurial per qualsiasi operazione interna tra repository differenti.

Ora, per rispondere alle altre domande:

• Puoi controllare quali teste hai con hg heads , se vedi 2+ teste in un singolo ramo con nome, è preferibile che siano unite. Probabilmente è qui che il tuo segnalibro è .
• Per eliminare una revisione appena creata, potresti fare hg rollback , ma suppongo che non sia così.
• Per eliminare un segnalibro basta fare hg bookmark --delete yourbookmark
• Sarai felice che sia facile tagliare rami nella storia. Esamina la estensione di Rebase e Operazione Start .
• Mercurial è già fornito in bundle con diverse estensioni, ma non sono attivate di default . Basta andare in qualsiasi cartella e fare clic destro ovunque per ottenere il menu di scelta rapida TortoiseHG, andare in Impostazioni globali e quindi estensioni: attivare l'estensione MQ e l'estensione Rebase. Questo non danneggia la compatibilità tra repository di qualsiasi tipo.
• Ora che sei qui, potresti:
  • Spoglia dove inizia il tuo segnalibro (probabilmente questo risolve il tuo problema)
  • Per una visualizzazione più semplice, potresti eventualmente ribaltare le modifiche nella parte anteriore e successivamente eliminarle. Ho appena citato rebase perché potrebbe essere qualcosa di utile per te un'altra volta.

Inoltre, in git puoi avere "rami locali privati" perché devi inviarli esplicitamente e puoi eliminarli in seguito. In Mercurial spinga tutto ciò che hai , tuttavia se vuoi evitare questo puoi utilizzare Funzione delle fasi e contrassegnare un insieme di revisioni come segreto . Le revisioni segrete non verranno spinte.

Infine, non stai facendo nulla di sbagliato , tieni presente che sono solo strumenti diversi costruiti con una mentalità leggermente diversa, che si riducono sostanzialmente a: modificare la cronologia (git) o non modificarla storia (hg). In Mercurial è più difficile spararti al piede modificando la cronologia (specialmente con le fasi) ed è per questo che alcuni lo apprezzano meglio di git .

Trovo che con il mercurio sia più facile non preoccuparsi dei rami. Ho appena trovato da dove nella cronologia voglio modificare e creare commit come richiesto (a.k.a rami anonimi). A volte i segnalibri possono essere utili se devo saltare tra le teste in diversi contesti, ma il più delle volte non mi preoccupo di loro. I rami denominati sono OK per rami a lungo termine (rami di bug fix, rami di progetto) ma per correzioni a 1 o 2 commit, non sono lo strumento adatto per il lavoro.

Il trucco con i rami anonimi è impostare la loro fase su "segreto" se non vuoi spingerli, ad esempio se vuoi mantenerli locali. Se fai vuoi spingerli, ma non vuoi più alcun commit basato su di essi, devi semplicemente commettere un "--close-branch" sopra di essi, il che significa che non appaiono più in la lista "teste" e mercuriale smetteranno di lamentarsi di più teste su quel ramo.

Penso che possiamo semplicemente usare il segnalibro invece del ramo; continueremo a supportare il prodotto in ogni caso e la fusione di due filiali a lungo termine sarebbe un grosso problema.