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

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

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

Hg .hgignore, синтаксис: glob совпадает с поведением .gitignore в git.

Git .git/config, ~/.gitconfig, используйте git-config для изменения значений
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 - это явное присутствие index или промежуточной области.

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

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

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

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

Хитрость в том, что вам действительно нужно понимать индекс, чтобы полностью использовать 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' или других расширений: вам нужно будет установить _ 7_ или CrecordExtension.
Но это не часть обычного рабочего процесса Mercurial.

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