| commit | 71538ca6e051b58dd1f71eb023f6226786246337 | [log] [tgz] |
|---|---|---|
| author | Luca Milanesio <luca.milanesio@gmail.com> | Sat Jul 26 18:13:57 2025 +0100 |
| committer | Luca Milanesio <luca.milanesio@gmail.com> | Mon Jul 28 07:11:27 2025 +0200 |
| tree | f42cc9686e3735d76a470fd6fd5071afc74a013e | |
| parent | ac66e589c8b03f4c7ea7b48c7bb3df7ba71df4b7 [diff] |
Consider the headName value when creating a new repository The creation of a new repository is notified through the ProjectCreatedEvent but the headName was ignored, causing the new project to be always created with a default head. Use the headName in the ProjectCreatedEvent and use it for creating the new empty repository. Also consider the 'headName' parameter when the creation happens via REST-API, even though the client-side of the replication via HTTP isn't implemented yet in this change and will be expanded in a follow-up change. Bug: Issue 430486435 Change-Id: I2a37b01e55c1acbc5e51bde365dd84c9943c9b31
This plugin can automatically mirror repositories from other systems.
Typically replication should be done over SSH, with a passwordless public/private key pair. On a trusted network it is also possible to use replication over the insecure (but much faster due to no authentication overhead or encryption) git:// protocol, by enabling the upload-pack service on the receiving system, but this configuration is not recommended. It is also possible to specify a local path as replication source. This makes sense if a network share is mounted to which the repositories should be replicated from.
To be allowed to trigger pull replication a user must be a member of a group that is granted the ‘Pull Replication’ capability (provided by this plugin) or the ‘Administrate Server’ capability.
Changes will be automatically indexed upon replication.
For more information please refer to the docs