Git-эквиваленты наиболее распространенных команд Mercurial?

Я использовал Mercurial, но хотел бы сделать быструю демонстрацию Git.

Каковы эквиваленты Git:

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?

Розеттский камень Git-HG неплох

Между этими двумя есть еще несколько ошибок, не упомянутых здесь. Этот список был взят из моего сообщения в блоге, когда я пошел другим путем (git -> hg).

Hg .hgignore , синтаксис: glob - это то же поведение, что и .gitignore git.

Git .git/config , ~/.gitconfigиспользуйте ГИТ-конфигурации , чтобы изменить значения
Hg .hg/hgrc , ~/.hgrcиспользуйтеhg 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 не предоставляет графический интерфейс для выбора ревизий, только консольную hg recordкоманду.

Git git rebase<br> Hg hg rebase . Потому git rebase --interactiveчто есть hg histedit или 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 . ; Обратите внимание на точку
Hg hg add ; Точка не требуется.

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

Чтобы заполнить пробелы, некоторые из самых полезных команд от Mercurial:

Hg hg record
Git git add -p; git commit

Hg hg inc [URL]
Git Нет эквивалента. Вы можете сделать только эквивалентhg pull; hg log -r .:

Hg hg out URL
Git Пожалуйста, добавьте, если знаете как.

Для разрешения конфликтов слияния у hg resolveкоманды в Mercurial есть несколько параметров, которые изменяют поведение:

Hg hg resolve -m FILE (отмечает, что файл был решен путем ручного устранения проблемы конфликта)
Git git add FILE

Hg hg resolve -u FILE отмечает файл как неразрешенный
Git, git reset HEAD FILE чтобы отключить файл

Hg hg resolve -l (перечисляет файлы с разрешенными / неразрешенными конфликтами)
Git git status - файлы, которые слились без ошибок, автоматически добавляются в индекс, те, которые не имеют конфликтов

Hg hg resolve FILE (после слияния пытается повторно слить файл)
Git нет эквивалента для повторного слияния, о котором я знаю.

Примечание: одно из самых больших различий между Git и Mercurial - это явное наличие индекса или промежуточной области .

Из Mercurial для пользователя Git :

Git - единственный DistributedSCM который раскрывает концепцию индекса или промежуточной области. Другие могут реализовать и скрыть это, но ни в каком другом случае пользователь не знает и не должен иметь с этим дело.

Примерный эквивалент Mercurial - это DirState, который контролирует информацию о состоянии рабочей копии, чтобы определить файлы, которые будут включены в следующую фиксацию. Но в любом случае этот файл обрабатывается автоматически.
Кроме того, можно быть более избирательным во время фиксации, указав файлы, которые вы хотите зафиксировать, в командной строке или используя расширение RecordExtension.

Если вам неудобно работать с индексом, вы переходите к лучшему ;-)

Хитрость в том, что вам действительно нужно понимать индекс, чтобы полностью использовать Git. Как напоминает нам эта статья от мая 2006 года (и это актуально и сейчас):

«Если вы отрицаете Индекс, вы действительно отрицаете сам git».

Теперь эта статья содержит много команд, которые теперь проще использовать (так что не слишком полагайтесь на ее содержание;)), но общая идея остается:

Вы работаете над новой функцией и начинаете вносить незначительные изменения в файл.

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

На этом этапе ваша следующая фиксация внесет 2 незначительных изменения в текущую ветку.

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

$ git commit

Записывает только изменения, добавленные в промежуточную область (индекс) на этом этапе, но не основные изменения, видимые в настоящее время в вашем рабочем каталоге.

$ git branch newFeature_Branch
$ git add myFile

Следующая фиксация запишет все другие важные изменения в новую ветку newFrature_Branch.

Теперь интерактивное добавление или даже разделение коммита - это функции, доступные в Mercurial с помощью команды ' hg record' или других расширений: вам нужно будет установить RecordExtensionили CrecordExtension.
Но это не часть обычного рабочего процесса Mercurial.

Git рассматривает фиксацию как серию « изменений содержимого файла » и позволяет вам добавлять эти изменения по одному.
Вы должны изучить эту функцию и ее последствия: Большинство Гит власти (например , возможность легко восстановить слияние (или разрез`ать проблему, или вернуть коммита) , в отличие от Mercurial ) происходит от этого «содержимое файла» парадигмы.

tonfa (в профиле: "Hg dev, pythonist": цифры ...) вмешался, в комментариях:

В индексе нет ничего принципиально "мерзкого", hg могла бы использовать индекс, если бы он был признан ценным, на самом деле mqили shelveуже был частью этого.

О, парень. Это снова мы.

Во-первых, я здесь не для того, чтобы один инструмент выглядел лучше другого. Я считаю Hg отличным, очень интуитивно понятным, с хорошей поддержкой (особенно в Windows, моей основной платформе, хотя я также работаю с Linux и Solaris8 или 10).

Индекс фактически является передним и центральным в том, как Линус Торвальдс работает с VCS :

Git использовал явные обновления индекса с первого дня, даже до первого слияния. Я просто так работал всегда. У меня есть грязные деревья с каким-то случайным патчем в моем дереве, который я не хочу фиксировать, потому что это просто обновление Makefile для следующей версии

Теперь комбинация индекса (которое встречается не только в Git) и парадигмы «контент - король» делает его довольно уникальным и «мерзким» :

git - это средство отслеживания содержимого , и имя файла не имеет значения, если оно не связано с его содержимым. Следовательно, единственное разумное поведение для git add filename - добавить содержимое файла, а также его имя в индекс.

Примечание: «содержание» здесь определяется следующим образом :

Индекс Git в основном определяется как

• достаточно, чтобы содержать полное « содержимое » дерева (а это включает все метаданные: имя файла, режим и содержимое файла - все это части «содержимого», и все они сами по себе бессмысленны! )
• дополнительная информация "stat", чтобы позволить очевидную и тривиальную (но чрезвычайно важную!) оптимизацию сравнения файловых систем.

Таким образом , вы действительно должны увидеть индекс , как быть содержанием .

Контент - это не «имя файла» или «содержимое файла» как отдельные части. Вы действительно не можете разделить их .
Сами по себе имена файлов не имеют смысла (у них тоже должно быть содержимое файла), а содержимое файла само по себе также бессмысленно (вы должны знать, как его получить).

Я пытаюсь сказать, что git принципиально не позволяет вам видеть имя файла без его содержимого. Вся эта идея безумна и неверна. Это не имеет отношения к «реальности».

Из FAQ основными преимуществами являются:

• совершить с высокой степенью детализации
• помочь вам сохранить незавершенную модификацию в вашем дереве в течение достаточно длительного времени
• выполните несколько небольших шагов для одной фиксации, проверяя, что вы сделали git diff, и подтверждая каждый маленький шаг с помощью git addили git add -u.
• позволяет отличное управление конфликтов слияния: git diff --base, git diff --ours, git diff --theirs.
• позволяет git commit --amendизменять только сообщение журнала, если индекс не был изменен за это время

Я лично считаю, что это поведение не должно быть по умолчанию, вы хотите, чтобы люди совершали что-то протестированное или, по крайней мере, скомпилированное.

Хотя в целом вы правы (насчет «протестированной или скомпилированной» части), способ, которым Git позволяет вам выполнять ветвление и слияние (выбор вишни или перебазирование), позволяет вам совершать коммиты так часто, как вы хотите, во временной частной ветке (только нажатием в удаленный «резервный» репозиторий), повторяя эти «уродливые коммиты» в общедоступной ветке со всеми необходимыми тестами.

Меркуриал:

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?

Эквиваленты Git:

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

Это примерно то же самое, без 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

Однако это команды, которые вы бы использовали при работе в одиночку. Вы попадаете в аккуратный материал, когда хотите объединить свои изменения с работой других людей с помощью git pullи git push, и связанных команд.