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

[multi-project-mapping]

git-branch-name = master

view = //depot/project1/main/... project1/...

//depot/project2/mainline/... project2/...

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

Последний файл, который мы обсудим, это users/p4gf_usermap; в нём задаётся отображение пользователей Perforce на пользователей Git. Возможно, вам не пригодится этот файл.

Когда Git Fusion преобразовывает набор изменений Perforce в Git коммит, он находит пользователя в этом файле и использует хранящиеся здесь адрес электронной почты и полное имя для заполнения полей "автор" и "применяющий изменения" в Git. При обратном процессе ищется пользователь Perforce с адресом электронной почты из поля "автор" 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).

Граф выглядит в точно как в Git. У Perforce не было именованной ветки для сохранения коммитов 1 и 2, так что он создал "анонимную" ветку в директории .git-fusion. Git Fusion поступит так же для именованных Git веток не соответствующих веткам в Perforce, но вы можете задать соответствие в конфигурационном файле.

Большинство происходящей магии скрыто от посторонних глаз, а в результате кто-то в команде может использовать Git, кто-то — Perforce и никто не будет подозревать о выборе других.

Если у вас есть (или вы можете получить) доступ к Perforce серверу, Git Fusion — это прекрасный способ подружить Git и Perforce. Конечно, требуется небольшая работа напильником, но в целом всё довольно интуитивно и просто. Это один из немногих разделов в этой главе, где мы не будем предупреждать вас об опасности использования всей функциональности Git. Но Perforce не всеяден: если вы попытаетесь переписать опубликованную историю, Git Fusion отклонит изменения. Тем не менее, Git Fusion будет стараться изо всех сил, чтобы не нарушать ваших привычек при работе с Git. Вы даже можете использовать подмодули Git (хотя они и будут выглядеть странными для Perforce пользователей) и сливать ветки (на стороне Perforce это будет выглядеть как интеграция).