# Allow dual mode: run from the command line just like the update hook, or
# if no arguments are given then run as a hook script
# if no arguments are given, then run as a hook script:
if[-n"$1"-a-n"$2"-a-n"$3"];then
# Output to the terminal in command line mode - if someone wanted to
# resend an email; they could redirect the output to sendmail
# themselves
# Output to the terminal in command line mode. If someone wanted to
# resend an email, they could redirect the output to sendmail themselves
PAGER= proxy_push $2$3$1
else
# Push is proxied upstream one ref at a time. Because of this it is possible
# for some refs to succeed, and others to fail. This will result in a failed
# push.
# Push is proxied upstream one ref at a time. It is possible for some refs
# to succeed, and others to fail. This results in a failed push.
while read oldrev newrev refname
do
proxy_push $oldrev$newrev$refname
...
...
@@ -126,9 +130,9 @@ else
fi
```
Note that this sample has a few limitations:
This sample has a few limitations:
-This example may not work verbatim for your use case and might need modification.
-It may not work for your use case without modification:
- It doesn't regard different types of authentication mechanisms for the mirror.
- It doesn't work with forced updates (rewriting history).
- Only branches that match the `allowlist` patterns are proxy pushed.
...
...
@@ -144,20 +148,24 @@ Bidirectional mirroring should not be used as a permanent configuration. Refer t
[Migrating from Perforce Helix](../../import/perforce.md) for alternative migration approaches.
[Git Fusion](https://www.perforce.com/manuals/git-fusion/#Git-Fusion/section_avy_hyc_gl.html) provides a Git interface
to [Perforce Helix](https://www.perforce.com/products) which can be used by GitLab to bidirectionally
mirror projects with GitLab. This can help you in some situations when migrating from Perforce Helix
to GitLab where overlapping Perforce Helix workspaces cannot be migrated simultaneously to GitLab.
to [Perforce Helix](https://www.perforce.com/products). GitLab can use the Perforce Helix
interface to bidirectionally mirror projects. It can help when migrating from Perforce Helix
to GitLab, if overlapping Perforce Helix workspaces cannot be migrated simultaneously.
If using mirroring with Perforce Helix, you should only mirror protected branches. Perforce Helix
If you mirror with Perforce Helix, mirror only protected branches. Perforce Helix
rejects any pushes that rewrite history. Only the fewest number of branches should be mirrored
due to the performance limitations of Git Fusion.
When configuring mirroring with Perforce Helix via Git Fusion, the following Git Fusion
settings are recommended:
When you configure mirroring with Perforce Helix by using Git Fusion, we recommend these Git Fusion
settings:
-`change-pusher` should be disabled. Otherwise, every commit is rewritten as being committed
by the mirroring account, rather than being mapped to existing Perforce Helix users or the `unknown_git` user.
-`unknown_git` user is used as the commit author if the GitLab user doesn't exist in
-Disable `change-pusher`. Otherwise, every commit is rewritten as being committed
by the mirroring account, rather than mapping to existing Perforce Helix users or the `unknown_git` user.
-Use the `unknown_git` user as the commit author, if the GitLab user doesn't exist in
Perforce Helix.
Read about [Git Fusion settings on Perforce.com](https://www.perforce.com/manuals/git-fusion/Content/Git-Fusion/section_vss_bdw_w3.html#section_zdp_zz1_3l).
## Related topics
-[Configure server hooks](../../../../administration/server_hooks.md) on a GitLab server.
