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

Ответ 1

Плохой камень Git -HG rosetta

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

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

Git.git/config, ~/.gitconfig, используйте Git -config для изменения значений Hg.hg/hgrc, ~/.hgrc, используйте hg help -c config

Git git commit -v
Hg hg diff | Меньше; hg commit

Git gitk
Hg hg, или thg из TortoiseHg

Git git gui
Hg Mercurial не отправляет графический интерфейс для выбора наборов изменений, только консоль hg record.

Git git rebase
Hg hg rebase. Для git rebase --interactive там hg histedit или Mercurial Queues

Git git push URL; git удаленный добавочный URL-адрес источника

Hg hg push URL; $EDITOR.hg/hgrc; [paths] default = URL

Git gitk, git журнал происхождения/мастер..HEAD
Hg hg исходящий

Git git format-patch RANGE
Hg hg email -m имя_файла -o

Git git добавить.; Обратите внимание на точку Hg hg add; Нет нужды.

Git git checkout ПЕРЕСМОТР ПЕРЕВОДА
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 добавить ФАЙЛ

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

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

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

Ответ 2

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

От Mercurial для Git Пользователь:

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

Меркуриальный приблизительный эквивалент - это 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 отображает фиксацию как серию изменений < содержимого файла "и позволяет добавлять эти изменения по одному за раз. Вы должны изучить эту особенность и ее последствия: Большая часть Git власти (например, способность легко вернуть слияние (или деактивировать проблему или вернуть фиксацию), вопреки Mercurial) происходит из этой парадигмы "содержимого файла".

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

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

О, мальчик. Здесь мы снова идем.

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

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

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

Теперь комбинация индекса (который не является понятием, видимым только в Git), а парадигма "контент является королем" делает его довольно уникальный и "git -ish" :

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

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

Git индекс в основном очень определен как

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

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

Содержимое не является" именем файла "или" содержимым файла "как отдельными частями. Вы действительно не можете отделить два.
Имена файлов сами по себе не имеют смысла (они также должны иметь содержимое файла), а содержимое файла само по себе также бессмысленно (вы должны знать, как его достичь).

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

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

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

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

В то время как вы правы в целом (о "проверенной или скомпилированной" части), способ Git позволяет вам разветвляться и объединяться (выбор вишни или перезарядки) позволяет совершать так часто, как вы хотите во временном (перенаправляется только в удаленный резервный репозиторий), в то время как повторное выполнение этих "уродливых коммитов" в публичном филиале, при этом все правильные тесты на месте.

Ответ 3

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?

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

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

Ответ 4

Это примерно то же самое, без 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, и связанными с ними командами.