Gli equivalenti Git dei più comuni comandi Mercurial?

Sto usando Mercurial ma vorrei fare una rapida demo di Git.

Quali sono gli equivalenti Git di:

hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?

La pietra di rosetta Git-HG non è male

Ci sono alcuni altri trucchi tra i due non menzionati qui. Questo elenco è stato preso dal mio post sul blog quando sono andato dall'altra parte (git -> hg).

Hg .hgignore , sintassi: glob ha lo stesso comportamento del .gitignore di git.

Git .git/config , ~/.gitconfig, uso git-config per modificare i valori
Hg .hg/hgrc , ~/.hgrc, usohg help -c config

Git git commit -v<br> Hg hg diff | less; hg commit

Git gitk<br> Hg hg view, or thg from [TortoiseHg][1]

Git git gui<br> Hg Mercurial non fornisce GUI per selezionare i changeset, solo il hg recordcomando della console .

Git git rebase<br> Hg hg rebase . Perché git rebase --interactivec'è hg histedit o Mercurial Queues

Git git push URL ; git remote add origin URL<br> Hg hg push URL; $EDITOR .hg/hgrc ; [paths] default = URL

Git gitk, git log origin/master..HEAD<br> Hg hg outgoing

Git git format-patch RANGE<br> Hg hg email -m filename -o

Git git add . ; Nota il punto
Hg hg add ; Nessun punto necessario.

Git git checkout REVISION-KEY<br> Hg hg update CHANGESET

Solo per riempire gli spazi, alcuni dei comandi più utili di Mercurial:

Hg hg record
Git git add -p; git commit

Hg hg inc [URL]
Git Nessun vero equivalente. Puoi fare solo l'equivalente dihg pull; hg log -r .:

Hg hg out URL
Git Per favore aggiungi se sai come.

Per la risoluzione dei conflitti di unione, il hg resolvecomando in Mercurial ha alcune opzioni che cambiano il comportamento:

Hg hg resolve -m FILE (contrassegna il file come risolto risolvendo manualmente il problema del conflitto)
Git git add FILE

Hg hg resolve -u FILE contrassegna il file come non risolto
Git git reset HEAD FILE per rimuovere lo stage del file

Hg hg resolve -l (elenca i file con conflitti risolti / non risolti)
Git git status - i file che sono stati uniti in modo pulito vengono aggiunti automaticamente all'indice, quelli che non sono hanno conflitti

Hg hg resolve FILE (dopo un'unione, tenta di unire nuovamente il file)
Git non è equivalente per la riunificazione che io sappia.

Nota: una delle maggiori differenze tra Git e Mercurial è la presenza esplicita dell'indice o dell'area di staging .

Da Mercurial per l'utente Git :

Git è l'unico DistributedSCM che espone il concetto di indice o area di staging. Gli altri possono implementarlo e nasconderlo, ma in nessun altro caso l'utente è a conoscenza né deve occuparsene.

L'equivalente approssimativo di Mercurial è il DirState, che controlla le informazioni sullo stato della copia di lavoro per determinare i file da includere nel commit successivo. In ogni caso, questo file viene gestito automaticamente.
Inoltre, è possibile essere più selettivi al momento del commit specificando i file che si desidera eseguire il commit sulla riga di comando o utilizzando il RecordExtension.

Se ti sei sentito a disagio nel trattare con l'indice, stai cambiando in meglio ;-)

Il trucco è che devi davvero capire l'indice per sfruttare appieno Git. Come ci ricorda allora questo articolo del maggio 2006 (ed è ancora vero ora):

"Se neghi l'indice, neghi davvero lo stesso git."

Ora, quell'articolo contiene molti comandi che ora sono più semplici da usare (quindi non fare troppo affidamento sul suo contenuto;)), ma l'idea generale rimane:

Stai lavorando a una nuova funzionalità e inizi ad apportare piccole modifiche a un file.

# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile

A questo punto, il tuo prossimo commit introdurrà 2 piccole modifiche nel ramo corrente

# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work

$ git commit

Registra solo le modifiche aggiunte all'area di staging (indice) a questo punto, non le modifiche principali attualmente visibili nella directory di lavoro.

$ git branch newFeature_Branch
$ git add myFile

Il prossimo commit registrerà tutte le altre modifiche principali nel nuovo ramo "newFrature_Branch".

Ora, l'aggiunta interattiva o anche la suddivisione di un commit sono funzionalità disponibili con Mercurial, tramite il hg recordcomando " " o altre estensioni: dovrai installare RecordExtension, o il file CrecordExtension.
Ma questo non fa parte del normale flusso di lavoro per Mercurial.

Git vede un commit come una serie di " modifiche al contenuto del file " e ti consente di aggiungere tali modifiche una alla volta.
Dovresti studiare quella caratteristica e le sue conseguenze: la maggior parte del potere di Git (come la capacità di annullare facilmente un'unione (o dividere in due il problema, o ripristinare un commit) , contrariamente a Mercurial ) deriva da quel paradigma del "contenuto di file".

tonfa (nel profilo: "Hg dev, pythonist": figures ...) è intervenuta, nei commenti:

Non c'è niente di fondamentalmente "git-ish" nell'indice, hg potrebbe usare un indice se fosse ritenuto prezioso, in effetti mqo shelvegià ne fa parte.

Oh ragazzo. Ci risiamo.

Primo, non sono qui per far sembrare uno strumento migliore di un altro. Trovo Hg fantastico, molto intuitivo, con un buon supporto (soprattutto su Windows, la mia piattaforma principale, anche se lavoro anche su Linux e Solaris8 o 10).

L'indice è in realtà davanti e al centro nel modo in cui Linus Torvalds lavora con un VCS :

Git ha utilizzato gli aggiornamenti espliciti dell'indice dal primo giorno, anche prima della prima unione. È semplicemente come ho sempre lavorato. Tendo ad avere alberi sporchi, con alcune patch casuali nel mio albero che non voglio inserire, perché è solo un aggiornamento del Makefile per la prossima versione

Ora la combinazione di index (che non è una nozione vista solo in Git) e il paradigma "content is king" lo rende piuttosto unico e "git-ish" :

git è un tracker di contenuti e il nome di un file non ha significato se non è associato al suo contenuto. Pertanto, l'unico comportamento corretto per git add filename è aggiungere il contenuto del file e il suo nome all'indice.

Nota: il "contenuto", qui, è definito come segue :

L'indice di Git è fondamentalmente molto definito come

• sufficiente a contenere il " contenuto " totale dell'albero (e questo include tutti i metadati: il nome del file, la modalità e il contenuto del file sono tutte parti del "contenuto" e sono tutti privi di significato da soli! )
• informazioni "stat" aggiuntive per consentire le ovvie e banali (ma estremamente importanti!) ottimizzazioni del confronto del filesystem.

Quindi si dovrebbe vedere l'indice come essendo il contenuto .

Il contenuto non è il "nome file" o il "contenuto file" come parti separate. Non puoi davvero separare i due .
I nomi dei file da soli non hanno senso (devono avere anche il contenuto del file), e il contenuto del file da solo è altrettanto insensato (devi sapere come raggiungerlo).

Quello che sto cercando di dire è che git fondamentalmente non ti consente di vedere un nome di file senza il suo contenuto. L'intera nozione è folle e non valida. Non ha rilevanza per la "realtà".

Dalle FAQ i principali vantaggi sono:

• impegnarsi con una granularità fine
• ti aiuta a mantenere una modifica non modificata nel tuo albero per un tempo ragionevolmente lungo
• esegui diversi piccoli passaggi per un commit, controllando cosa hai fatto git diffe convalidando ogni piccolo passaggio con git addo git add -u.
• permette un'ottima gestione dei conflitti di unione: git diff --base, git diff --ours, git diff --theirs.
• permette git commit --amenddi modificare solo il messaggio di log se nel frattempo l'indice non è stato modificato

Personalmente penso che questo comportamento non dovrebbe essere l'impostazione predefinita, vuoi che le persone inviino qualcosa che viene testato o almeno compilato

Sebbene tu abbia ragione in generale (riguardo alla parte "testata o compilata"), il modo in cui Git ti consente di ramificare e fondere (selezione o ribasatura) ti consente di eseguire il commit tutte le volte che vuoi in un ramo privato temporaneo (solo push al repository di "backup" remoto), mentre si rifanno quei "brutti commit" su un ramo pubblico, con tutti i test giusti in atto.

Mercurial:

hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?

Equivalenti Git:

git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status

È più o meno lo stesso, senza addremove:

git init # Start a project in the current directory
git status # Displays both changes and added/removed files
git commit -m "comment" # commit any uncommited changes

Tuttavia, questi sono comandi che useresti quando lavori da solo. Ti occupi di cose chiare quando vuoi unire le tue modifiche con il lavoro di altre persone con git pulle git push, e i comandi correlati.