Скотт Чакон - Pro Git

git log показывает два коммита, на последнюю из которых указывает довольно много ссылок. На самом деле, не все из них реально существуют. Давайте-ка посмотрим, что хранится внутри директории .git:

$tree .git/refs

.git/refs

├── heads

│ └── master

├── hg

│ └── origin

│ ├── bookmarks

│ │ └── master

│ └── branches

│ └── default

├── notes

│ └── hg

├── remotes

│ └── origin

│ └── HEAD

└── tags

9 directories, 5 files

git-remote-hg пытается нивелировать различия между Git и Mercurial, преобразовывая форматы за кулисами. Ссылки на объекты в удалённом репозитории хранятся в директории refs/hg. Например, refs/hg/origin/branches/default — это Git-ссылка, содержащая SHA-1 "ac7955c" — коммит на который ссылается ветка master. Таким образом, директория refs/hg — это что-то типа refs/remotes/origin, с той разницей что здесь же отдельно хранятся Mercurial-закладки и ветки.

Файл notes/hg — отправная точка для выяснения соответствия между хешами коммитов в Git и идентификаторами ревизий в Mercurial. Давайте посмотрим что там:

$cat notes/hg

d4c10386...

$git cat-file -p d4c10386...

tree 1781c96...

author remote-hg <> 1408066400 -0800

committer remote-hg <> 1408066400 -0800

Notes for master

$git ls-tree 1781c96...

100644 blob ac9117f... 65bb417...

100644 blob 485e178... ac7955c...

$git cat-file -p ac9117f

0a04b987be5ae354b710cefeba0e2d9de7ad41a9

Итак, refs/notes/hg указывает на дерево, которое содержит список других объектов и имён. Команда git ls-tree выводит права доступа, тип, хеш и имя файла для содержимого дерева. Наконец, добравшись до первого элемента дерева, мы обнаружим, что это блоб с названием "ac9117f" (SHA-1 коммита, на которую указывает ветка master), содержащий "0a04b98" (идентификатор последней ревизии ветки default в Mercurial).

Всё это немного запутанно, но хорошие новости в том, что, по большому счёту, нам не нужно беспокоится об организации данных в git-remote-hg. В целом, работа с Mercurial сервером не сильно отличается от работы с Git сервером.

Ещё одна вещь, которую следует учитывать: список игнорируемых файлов. Mercurial и Git используют очень похожие механизмы для таких списков, но всё же хранить .gitignore в Mercurial репозитории — не самая удачная идея. К счастью, в Git есть механизм игнорирования специфичных для локальной копии репозитория файлов, а формат списка исключений в Mercurial совместим с Git, так что можно просто скопировать .hgignore кое-куда:

$cp .hgignore .git/info/exclude

Файл .git/info/exclude работает подобно .gitignore, но не фиксируется в истории изменений.

Предположим, вы проделали некую работу, зафиксировали изменения в ветке master и готовы отправить изменения в удалённый репозиторий. Вот как выглядит репозиторий сейчас:

$git log --oneline --graph --decorate

* ba04a2a (HEAD, master) Update makefile

* d25d16f Goodbye

* ac7955c (origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master) Create a makefile

* 65bb417 Create a standard "hello, world" program

Наша ветка master опережает origin/master на два коммита, пока что они есть лишь в локальном репозитории. Давайте посмотрим, вдруг кто-нибудь сделал важные изменения:

$git fetch

From hg::/tmp/hello

ac7955c..df85e87 master -> origin/master

ac7955c..df85e87 branches/default -> origin/branches/default

$git log --oneline --graph --decorate --all

* 7b07969 (refs/notes/hg) Notes for default

* d4c1038 Notes for master

* df85e87 (origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master) Add some documentation

| * ba04a2a (HEAD, master) Update makefile

| * d25d16f Goodbye

|/

* ac7955c Create a makefile

* 65bb417 Create a standard "hello, world" program

Из-за того, что мы использовали флаг --all, выводятся ссылки "notes", используемые внутри git-remote-hg, можно не обращать на них внимания. В остальном, ничего необычного: origin/master продвинулся на один коммит и история разошлась. В отличие от остальных систем контроля версий, рассматриваемых в этой главе, Mercurial умеет работать со слияниями, так что мы не будет вытворять никаких фокусов.

$git merge origin/master

Auto-merging hello.c

Merge made by the 'recursive' strategy.

hello.c | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

$git log --oneline --graph --decorate

* 0c64627 (HEAD, master) Merge remote-tracking branch 'origin/master'

|\

| * df85e87 (origin/master, origin/branches/default, origin/HEAD, refs/hg/origin/branches/default, refs/hg/origin/bookmarks/master) Add some documentation

* | ba04a2a Update makefile

* | d25d16f Goodbye

|/

* ac7955c Create a makefile

* 65bb417 Create a standard "hello, world" program

Отлично! Мы запустили все тесты, они прошли, так что всё готово для отправки изменений на удалённый сервер:

$git push

To hg::/tmp/hello

df85e87..0c64627 master -> master

Вот и всё! Если теперь посмотреть на Mercurial репозиторий, мы не увидим там ничего необычного:

$hg log -G --style compact

o 5[tip]:4,2 dc8fa4f932b8 2014-08-14 19:33 -0700 ben

|\ Merge remote-tracking branch 'origin/master'

| |

| o 4 64f27bcefc35 2014-08-14 19:27 -0700 ben

| | Update makefile

| |

| o 3:1 4256fc29598f 2014-08-14 19:27 -0700 ben

| | Goodbye

| |

@ | 2 7db0b4848b3c 2014-08-14 19:30 -0700 ben

|/ Add some documentation

|

o 1 82e55d328c8c 2005-08-26 01:21 -0700 mpm

| Create a makefile

|

o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm

Create a standard "hello, world" program

Набор изменений 2 был произведён Mercurial’ом, а изменения 3 и 4 внесены git-remote-hg после отправки изменений, сделанных через Git.

В Git есть только один тип веток: указатель, который передвигается "вперёд" по мере коммита изменений. В Mercurial такие указатели называются "закладки" и ведут себя схожим с Git образом.

Понятие "ветка" в Mercurial означает немного другое. Название ветки, в которой происходят изменения, записывается внутри каждого набора изменений и, таким образом, навсегда остаётся в истории. Например, вот один из коммитов, произведённых в ветке develop:

$hg log -l 1

changeset: 6:8f65e5e02793

branch: develop

tag: tip

user: Ben Straub

date: Thu Aug 14 20:06:38 2014 -0700

summary: More documentation

Обратите внимание на строку, начинающуюся с "branch". Git устроен по-другому (на самом деле, оба типа веток могут быть представлены как ссылки в Git), но git-remote-hg вынужден понимать разницу, потому что нацелен на работу с Mercurial.

Создание "закладок" Mercurial не сложнее создания простых веток в Git. Вот что мы делаем в Git:

$git checkout -b featureA

Switched to a new branch 'featureA'

$git push origin featureA

To hg::/tmp/hello

* [new branch] featureA -> featureA

А со стороны Mercurial это выглядит так:

$hg bookmarks

featureA 5:bd5ac26f11f9

$hg log --style compact -G

@ 6[tip] 8f65e5e02793 2014-08-14 20:06 -0700 ben

| More documentation

|

o 5[featureA]:4,2 bd5ac26f11f9 2014-08-14 20:02 -0700 ben

|\ Merge remote-tracking branch 'origin/master'

| |

| o 4 0434aaa6b91f 2014-08-14 20:01 -0700 ben

| | update makefile

| |

| o 3:1 318914536c86 2014-08-14 20:00 -0700 ben

| | goodbye

| |

o | 2 f098c7f45c4f 2014-08-14 20:01 -0700 ben

|/ Add some documentation

|

o 1 82e55d328c8c 2005-08-26 01:21 -0700 mpm

| Create a makefile

|

o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm

Create a standard "hello, world" program

Обратите внимание на метку [featureA] на пятой ревизии. Таким образом, со стороны Git "закладки" выглядят как обычные ветки с одним лишь исключением: нельзя удалить закладку через Git (это одно из ограничений обёрток для взаимодействия с другими СКВ).

Можно работать и с полноценными ветками Mercurial — просто поместите Git ветку в пространство имён branches:

$git checkout -b branches/permanent