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

В большинстве случаев это нормальное поведение, но что будет, если соответствия выглядят так:

john john@example.com "John Doe"

john johnny@appleseed.net "John Doe"

bob employeeX@example.com "Anon X. Mouse"

joe employeeY@example.com "Anon Y. Mouse"

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

Последний две строки скрывают настоящие имена Боба и Джо в созданных Git коммитах. Это может быть полезным, если вы хотите отдать внутренний проект в open-source, но не хотите раскрывать информацию о сотрудниках. Адреса электронной почты и полные имена должны быть уникальными если вы хотите хоть как-то различать авторов в полученном Git репозитории.

Perforce Git Fusion — это двунаправленный "мост" между Perforce и Git. Давайте посмотрим, как выглядит работа со стороны Git. Предполагается, что мы настроили отображение проекта "Jam", используя приведённую выше конфигурацию. Тогда мы можем клонировать его:

$git clone https://10.0.1.254/Jam

Cloning into 'Jam'...

Username for 'https://10.0.1.254': john

Password for 'https://ben@10.0.1.254':

remote: Counting objects: 2070, done.

remote: Compressing objects: 100% (1704/1704), done.

Receiving objects: 100% (2070/2070), 1.21 MiB | 0 bytes/s, done.

remote: Total 2070 (delta 1242), reused 0 (delta 0)

Resolving deltas: 100% (1242/1242), done.

Checking connectivity... done.

$git branch -a

* master

remotes/origin/HEAD -> origin/master

remotes/origin/master

remotes/origin/rel2.1

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

* 0a38c33 (origin/rel2.1) Create Jam 2.1 release branch.

| * d254865 (HEAD, origin/master, origin/HEAD, master) Upgrade to latest metrowerks on Beos -- the Intel one.

| * bd2f54a Put in fix for jam's NT handle leak.

| * c0f29e7 Fix URL in a jam doc

| * cc644ac Radstone's lynx port.

[...]

В первый раз этот процесс может занять некоторое время. Git Fusion преобразовывает все наборы изменений Perforce в Git коммиты. Данные преобразуются локально на сервере, так что это вполне быстрый процесс; тем не менее, он может слегка затянуться, если у вас большая история изменений. Последующие скачивания требуют лишь инкрементального преобразования данных, таким образом скорость будет сравнима со скоростью работы обычного Git сервера.

Как видите, наш репозиторий выглядит так же, как выглядел бы любой другой Git репозиторий. В нём три ветки и Git предусмотрительно создал локальную ветку master, отслеживающую origin/master. Давайте немного поработаем и зафиксируем изменения:

#...

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

* cfd46ab (HEAD, master) Add documentation for new feature

* a730d77 Whitespace

* d254865 (origin/master, origin/HEAD) Upgrade to latest metrowerks on Beos -- the Intel one.

* bd2f54a Put in fix for jam's NT handle leak.

[...]

Теперь у нас два новых коммита. Проверим, какие изменения внесли другие:

$git fetch

remote: Counting objects: 5, done.

remote: Compressing objects: 100% (3/3), done.

remote: Total 3 (delta 2), reused 0 (delta 0)

Unpacking objects: 100% (3/3), done.

From https://10.0.1.254/Jam

d254865..6afeb15 master -> origin/master

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

* 6afeb15 (origin/master, origin/HEAD) Update copyright

| * cfd46ab (HEAD, master) Add documentation for new feature

| * a730d77 Whitespace

|/

* d254865 Upgrade to latest metrowerks on Beos -- the Intel one.

* bd2f54a Put in fix for jam's NT handle leak.

[...]

Кто-то успел отправить свои изменения раньше нас! Конечно, из приведённого вывода команды git fetch не видно, но на самом деле коммит с SHA-1 6afeb15 был создан Perforce клиентом. Он выглядит так же, как и любой другой коммит, и это именно то, для чего создан Git Fusion. Давайте посмотрим, как Perforce обработает коммит-слияние:

$git merge origin/master

Auto-merging README

Merge made by the 'recursive' strategy.

README | 2 +-

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

$git push

Counting objects: 9, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (9/9), done.

Writing objects: 100% (9/9), 917 bytes | 0 bytes/s, done.

Total 9 (delta 6), reused 0 (delta 0)

remote: Perforce: 100% (3/3) Loading commit tree into memory...

remote: Perforce: 100% (5/5) Finding child commits...

remote: Perforce: Running git fast-export...

remote: Perforce: 100% (3/3) Checking commits...

remote: Processing will continue even if connection is closed.

remote: Perforce: 100% (3/3) Copying changelists...

remote: Perforce: Submitting new Git commit objects to Perforce: 4

To https://10.0.1.254/Jam

6afeb15..89cba2b master -> master

Со стороны Git всё работает как положено. Давайте посмотрим на историю файла README со стороны Perforce, используя p4v:

Рисунок 2. Граф ревизий Perforce после отправки данных из Git.

Если вы ни разу не работали с Perforce это окно может показаться вам запутанным, но его концепция аналогичная gitk. Мы просматриваем историю файла README, так что дерево с директориями слева вверху показывает этот файл в разных ветках. Справа вверху мы видим граф зависимости разных ревизий файла, справа внизу этот же граф показан целиком для быстрого ориентирования. Оставшаяся часть окна отображает детали выбранной ревизии (в нашем случае это ревизия 2).